一周技术学习笔记(第89期)-共享服务放大就是中台

整个架构结构发展的历程，大概是从单体到分布式，到SOA，到微服务，最后或者说是现在的中台。

图自《架构实战案例解析》

这个历程，以及最终结果的产生，都是因为系统要不断适应业务复杂化。

一个业务流程从开始到结束的长度，我们称之为业务的深度。自然也就有它自身的复杂性。比如查看商品详情，自然要将商品信息从数据库里面读取出来，然后需要组装商品的促销信息和价格，以及有无商品标签，比如7天无理由退货等等，最后将全面的商品信息展示给用户。

其实，在单体的时候，它是很清晰的能把这种业务流程的深度展示清楚的。

图自《架构实战案例解析》

但是呢，业务流程不仅仅只有从页面到数据库这样的简单。比如一个电商的下单流程，先浏览商品详情，加入购物车，提交订单，最终进行支付，如果要考虑后续的履约流程，那么这个业务流程模块就会更多。

这个时候，单体应用就缺乏清晰的边界，模块结构是否合理，很大程度上只能依赖于程序员的个人水平。

即使个人的水平很高，那么他处理一个把首页、搜索页、详情页、支付页等所有的功能在一起的系统里面也是一个很大的心理负担和挑战。而且，当这样的每个模块的业务都变得越来越复杂的时候，程序员就要维护一个庞大的网状依赖系统。

业务的复杂度急剧上升，模块的数量大幅增加。

所以就开始分，人类最聪明的地方，就是善于把大事化小，把整体化零碎。

你可以看到分布式、微服务都是这样的思路。这样就把一个大系统的业务复杂度，分割成多个小业务的复杂度，从而降低了整体的复杂度。从而进行了业务广度上的切分。

微服务架构= 80% 的SOA 服务架构思想+ 100% 的组件化架构思想+ 80% 的领域建模思想。

封装底层基础业务的是共享微服务，封装流程的是聚合微服务，封装具体业务场景的服务端是应用微服务，封装基础中间件（如 Redis 缓存、消息推送）的是系统微服务。

把共享微服务放大，就是中台。

参考资料：《架构实战案例解析》

----END----

这里记录，我每周碰到的，或想到的，引起触动，或感动的，事物的思考及笔记。不见得都对，但开始思考记录总是好的。