我周末参加了个架构师大会！

Fri, 31 Dec 2021 12:54:57 +0800

大家好，我是煎鱼。

前两天 GIAC 全球互联网架构大会在深圳举办了，总算是有个长年在深圳举办的大会了，愉快参加了大部分的场次，面基了不少社区网友。

分享一些我听了觉得有意义的记录给大家。希望能和大家一起学习进步。本文分别涉及如下几个议题：

hits for microservices desgin

一开始先介绍了为什么叫 ”hits“。叫 ”hits“ 的主要原因，是业务架构没有技术架构那么明确，没有明确的对与错，是个人的工作经验和总结。

业内常常说到，微服务，微服务。总归期望微服务解决什么问题。

演讲的作者做了如下的调研：

从调研结果来看，占比最大的就是 ”独立自治，只关注自己的模块“。这和绝大部分既有业务的公司做微服务的初衷一致。

许多就是被单体的巨石应用折腾的不行，纷纷希望通过拆分微服务来实现业务模块的独立自治。

主要是播放了动图，配合口述。现在大多数服务拆分后的现状，很多就是改哪影响哪完全不清楚，和水管漏水似的：

(自行脑补一拧水管，堵哪，别的地方就漏)

理想中的微服务拆分，希望要有灵活的组装能力。但拆分后遇到的新问题，实际的情况，拆分后与期望的不一样，拆着拆着就变成了一大坨，但只是说隔开了，与现在企业中微服务运行的现状很贴合。

拆分后如有如下几个痛点：

举了几个案例。分别是：

举的是订单的例子，订单团队非常忙，因为信息都存在订单里，系统其他有任何业务上的变更诉求，都要找订单的团队。

为此，在拆分上需要优化成订单业务只保存订单 ID：

各系统存订单ID，各团队自治，实现业务解耦，订单团队就不用因其他业务变更天天加班了。

举的是报价的系统，要是报价团队，针对各个子业务项都要自己实现一般，会非常的辛苦，经常要加班。

我们只需要在报价系统提供接口标准，各系统自己实现，再对接：

报价团队就不需要每次都重新开会，再对接。报价系统自己只做业务流程的编排，瞬间变轻松了。

举的是数仓的例子，业务改一个字段，数仓系统要改一个月，否则就会出现问题，因此要求业务有任何 schema 改变都必须要通知数仓团队：

很现实的是，基本通知不过来，所以很多公司把他作为绩效，定期考核，出问题定期批评。

建议的是：通过 RPC 的方式提供维护，把数据维护交给业务团队自己维护，数仓团队应该只做具体的跨团队的数据互联。

分层，都可以独立变更，可以自己搞自己，只需要保证这一层提供的能力是稳定的就好（全部改一遍的另当别论），不需要了解上下游，只需要维护好 interface。

具体几点：

参照乐高，关注接口的稳定性，而不是拆的越细越好。