很多人不知道SOA、微服务、中台有啥用。都理解的有偏差，认为他们能解决自己某的棘手问题，但仔细真实一用发现还不行。所以对这些东西就产生了困惑甚至反对，说这些东西是骗子。

　　所以我今天拿实践给大家讲讲这些东西具体实际怎么用，具体实际是怎么解决问题的，他们到底真实能解决啥问题。

　　（1）服务治理

　　一、背景介绍

　　某公司从来没想到过自己会发展的那么快、那么大，所以随着业务快速扩张，天天赶着、救着火

　　二、突出问题

　　由于业务需要，所以建设了许多系统。而且由于发展比较快，所以在研发这些系统的时候也没注意架构精巧设计。所以到后来，系统之间的互相调用越来越交叉复杂。导致出现了出现了异常问题，谁也找不到问题根源，很多事情不了了之。大家都不知道下一个时刻会不会出现问题、会出现什么问题。天天活在茫然和恐惧的心理压力焦虑当中。

　　三、解决手段

　　一次重大异常，痛定思痛，开始招聘专门的应用架构设计师，成立专门的应用架构部门。这帮人的目标就是做服务切割隔离、服务治理。

　　所以这帮人来了以后就先开始梳理各个系统之间的复杂调用关系。

　　然后和骨干程序员了解每个复杂调用关系的业务原理。

　　然后思考如何切割隔离这些交叉调用关系。

　　最后，用服务网关、服务总线，把这些切割隔离的调用关系理顺，再按业务原理接回去。

　　以后再有相互的事，就按新的原则规定和方法来搞，就不会以后再出现蜘蛛网调用难以快速找到问题根源的难题了。

　　四、效果

　　做完这次大重构后，每个研发Team各自负责各自的模块，自己更新自己，不用牵一发动全身，也不会使问题水漫给别人。

　　出了问题也聚焦在自己这块来找问题，而不是到处找别人问题

　　（2）微服务

　　一、背景介绍

　　某公司经过服务治理完后，又出现了新问题。那就是因为业务量起量非常快，高并发堵塞严重。

　　二、解决手段

　　哪里堵，就把那块堵点的代码单独提出来，然后单独部署、分布式部署

　　三、效果

　　随着堵点一个个被这样解决，堵点问题解决

　　（3）中台

　　一、背景介绍

　　某公司发起了一个“被集成”的战略，也就是说：让自己的业务内嵌到别人的流量平台里，比如嵌入到抖音里...

　　二、突出问题

　　随着嵌入的越多，发现口子太多了，需要有一个东西要统一收一下口，把这么多口子来的客户、订单等等信息收到这个口子里

　　三、解决手段

　　把自己过去常规用的订单数据服务、订单管理中心、客户数据服务、客户管理中心、库存数据服务、库存管理中心等等模块都专门提出来，独立部署，精心设计好对外的统一接口，以便自己的关联系统、外部的关联平台，都统一使用这些公共应用模块。这就成了业务中台

　　四、效果

　　以后再增加新的连接口，都可以很快连接上，而且还井井有条不乱。

　　另外，和企业内部使用的ERP系统形成了良好的集成性，有了业务中台，让来自不同流量口的访问和数据不至于直接冲击到内部ERP系统，起到了内外缓冲中间承接的价值。