一口气说透中台--给你架构师的视角( 二 ) _中台

这时候就会有人问了，这得拆多少个微服务？这对管理简直是一个灾难！各管一滩事，谁去统一管控？所以微服务架构还有一个事情是必须做的，就是增加管理组件。这些组件的核心作用就是对各种微服务进行统一管控，不仅能管理微服务的全生命周期，还能在某个微服务被流量撑爆的时候进行各种丢车保帅的操作，在长长的链路中，可以不断向下跟踪，发现问题的根源。

文章插图

服务网格架构
是的，您发现了，解决一个问题必然会带来其他问题。微服务做到了进一步解耦，解决了很多分层架构的很多问题，但是遇到了以下挑战：

每个微服务可能会用不同语言的不同版本

有太多的基础框架和工具需要学习

所有的client、server都需要维护n个版本

上下游需要同步升级，否则你懂的

解决办法呢？能不能进一步解耦？有人说了，都解耦到这种程度了，再解，那得变成啥德行啊？
还真可以。

文章插图

这个时候，我们的整个微服务体系，就变成了这个网格的样子，所以叫服务网格架构。

文章插图

这个架构的好处就显而易见了，所有的通信都让代理实现，服务就只做自己的业务逻辑处理就好了。所有的跨语言问题、各个微服务版本的问题、上下游的问题全部解决了。
中台架构
懒婆娘的裹脚布，终于一层层的解开到最后，终于该说中台架构了。以服务网格架构为分界线，前面的架构优化思路只有一个，就是“拆” 。到服务网格，就没法再拆下去了，那么还有更好的模式吗？既然提到了中台，那么这自然就是解决之道。
Supercell的故事就不用再重复了。这里必须八卦一下阿里和腾讯，阿里向Supercell学习了中台方法论，并把它进化成超级武器；腾讯把Supercell收购了，却只是用来继续做游戏。从组织的角度上来说，阿里完胜。
每个微服务都是个性化的，在单一业务线中，这就是最优的架构。但是业务线一多，或者上下游系统太多，每条业务线都在重复造轮子，存在大量资源浪费的情况；不同业务线之间的数据也是孤立的，无法打通。那该怎么办呢？

文章插图

是的，信息系统的核心就是抽象，我们在业务线之上，再抽象一层就完了。所以中台架构的核心思想不再是“拆”了，而是“合” 。各自的微服务中必然就有共同的服务，我们可以把这些共同的服务合并、标准化、统一化，封装后对外提供服务。所以就会出现各种中心，这些中心的组合，就是中台：

文章插图

在业务逻辑部分做这种抽象整合重组，就是业务中台；
在数据部分做这种抽象整合重组，就是数据中台；
在算法部分做这种抽象整合重组，就是算法中台；
在技术底层做这种抽象整合重组，就是技术中台。
而想要实现上述任何一种中台，必须要先做组织的抽象整合重组，这就是组织中台。这也说明了，任何一个中台并不是孤立的，没有组织中台，妄想单独做其中一个中台，把中台当做银弹，那么必死无疑。
作者：彭文华大数据架构师分享数据分析、大数据技术、数仓建设相关的技术、方法论、案例、解决方案。