SOA微服务中台的真实实践案例

Posted david_lv

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了SOA微服务中台的真实实践案例相关的知识,希望对你有一定的参考价值。

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

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

(1)服务治理

一、背景介绍

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

二、突出问题

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

三、解决手段

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

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

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

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

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

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

四、效果

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

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

(2)微服务

一、背景介绍

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

二、解决手段

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

三、效果

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

(3)中台

一、背景介绍

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

二、突出问题

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

三、解决手段

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

四、效果

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

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

以上是关于SOA微服务中台的真实实践案例的主要内容,如果未能解决你的问题,请参考以下文章

苏宁数据中台基于Spring Cloud微服务架构实践

微服务中台落地 中台误区

六种常用的微服务架构设计模式(建议收藏)

微服务中台技术解析之分布式事务方案和实践

朱晔的互联网架构实践心得S2E4:小议微服务的各种玩法(古典SOA传统K8SServiceMesh)

Atitit.架构设计趋势 设计模式 ---微服务架构  soa