公司内做的一个简单的分享,文章内容是我根据自己讲的还有录音又手撸了一遍,累,口语化的做简单修改。
今天给大家分享一下关于架构和中台的一些东西。
主要会介绍一下中台的来源,这个大家可能都比较清楚,网上的文章和视频啊一大堆。
还有就是关于架构的发展过程不得不在中间说明一下,由此引申出来中台的诞生。
最后会就关于交易中台和金融中台做一个介绍,因为我最近两年在其他公司做的一个是交易中台,还有一个就是金融中台相关的业务。
中台由来
首先,来看一下中台的由来。
中台的来源主要是阿里,他们在15年拜访在芬兰的一家游戏公司,也就是SuperCell。
这家公司非常牛逼,号称是世界上最成功的的移动游戏公司,做出的游戏也非常有名,肯定很多人也玩过。
比如部落战争、海岛奇兵等等。
![73faf370fc0aa348eb15770ad5bad916.png](https://i-blog.csdnimg.cn/blog_migrate/5792da35a43dbd7e850cb9895799fddf.png)
我也玩过一下他们的那个游戏,不过觉得没啥意思。
这家公司的规模只有不到200人,公司的开发模式通常都会由2-7个人的小团队进行开发,这个在他们内部叫做cell,这也是他们公司名字的由来。
开发过程通常是团队内部决定,然后用最快的时间开发出测试版本,如果受欢迎就继续干,否则的话就迅速放弃。
产品失败之后,不光不会受到惩罚,他们还会搞个party来庆祝,庆祝自己学到了新的东西。
不过我觉得挺奇葩的,要是都按照他们这个模式来,早期腾讯、阿里这些大公司都该死绝了。
我们都知道,腾讯早期的时候想卖100万都没人要,马总实在没辙才只能硬着头皮继续做下去。
但是,就是这样一家小公司,2015年的净利润达到了15亿美元,而且在2016年的时候被腾讯86亿美元收购。
这些都不是重点哈,重点我们今天要讲的是他们的开发模式,为什么能快速开发一个新游戏出来?
本来在我们想象中,开发一个新的游戏是一个很耗费时间精力的东西,几周开发一个还不错的游戏应该是很有难度的事情。
重点就在于他们的”中台“,也是他们多年游戏沉淀下来的东西。
他们在前面的很多年时间里对通用的游戏素材、算法等等做了很多沉淀。
这也就是后面阿里之后大力搞的中台了。
聊聊架构
讲完中台的来历,在将中台之前,我们还是要先说说架构的发展过程。
单体架构的时代
在我刚刚上班的时候,大概是11年、12年基本上我接触到的项目都是这个样子。
一个团队的所有东西都在一块,什么用户注册登录、支付啊、订单都在一起,经常是改一个小东西一个大项目都要跟着发布。
一般单体的架构都是单进程的,这也是针对我们现在的微服务来说的,就是打个jar包或者war包上传就完事儿了,所有模块都在一个进程里,如果要升级或者重启,那整个应用服务都要重启。
当然了,简单的项目划分模块分层还是有的,比如我们那时候常用的MVC模式。
![fe3edb32df9dbb82d77c788349dc0369.png](https://i-blog.csdnimg.cn/blog_migrate/f241b727d77437039897c5aa7b4bd2c0.png)
简单是很简单,但是同样缺点也是很明显的。
第一点就是团队协同合作的成本高,如果说小公司没几个人还好,一旦业务快速发展起来,代码量感人,刚开始上班那会儿我的电脑经常就只能跑的动一个项目,不过好像也没有别的项目了。
经常改一个简单的东西可能到处是冲突,更不要说一个大服务的发版问题。
第二点,项目太复杂了,什么东西都是大杂烩,全在里面。
第三点,数据库连接的问题,一个服务太大了,就一个数据库的集群,业务越来越多,服务器越来越多,到后面单机可能只搞个个位数的连接都要不够用了。
所以,一般伴随拆分服务,数据库也会做拆分,独立的服务拥有独立的数据库。
最后一点,拓展性的问题,所有的功能都在一个服务里,可能实际情况是某几个功能模块负载非常高,比如订单或者库存的服务,频繁的读写,这时候想要扩展很难搞。
更严重的问题就是,如果一个模块出了问题,整个应用都不能用了。
这时候没有办法了,只能拆分。
因此就到了我们第二个架构模式,SOA的时代。
SOA(Service-Oriented Architecture)
我在饿了么工作那会儿,里面就有一大堆的SOA的称呼,并且一直都是。
SOA是什么意思呢,全名是这个Service-Oriented Architecture,意思就是面向服务的架构,基本上和我们现在的微服务差不多一样。
SOA的核心在于:松耦合和服务重用,当单体架构出现瓶颈的时候,首先想到的都是拆,SOA时代的话,其实也已经就有了服务注册发现、服务治理这些概念了,和微服务可以说从认知上没有任何区别。
SOA其实有两种模式,一种是中心化,一种是去中心化,下图中表示的就是中心化的服务调用方式。
![1a13abc9c971f13da5041738e91758bd.png](https://i-blog.csdnimg.cn/blog_migrate/4104e0671c247ff42972ca4901e586f4.png)
服务调用之间都通过ESB服务总线,调用方之间屏蔽了接口的修改,ESB要做服务请求路由、数据格式转换,各种HTTP SOCKET适配和接入,所有脏活累活都归他干了。
这样很明显的看出来问题了。
第一个就是请求,同样的请求次数是通常去中心化的2倍,本来A调用B,现在要通过ESB。
第二个是肉眼可见的问题,这个ESB的压力会非常大,可以通过集群解决,但是ESB的性能瓶颈会导致所有服务的瓶颈。
但是,这个模式在当初非常受欢迎,主要原因是什么呢?
就是烟囱式架构引发出来的问题。
烟囱式架构是什么?
![70a73cf58ffa92212b7f3d912e57af38.png](https://i-blog.csdnimg.cn/blog_migrate/c3b9142a48caa6b5f0f3b1482232f653.png)
就像这张图描述的,你有好几个业务,因为时间或者说团队、公司各种原因,搞成了好几套独立的服务,开发和运维都没啥关系,大多数公司之前的发展过程中都会存在这样的问题。
比如我之前的公司先做酒店业务、然后又有外卖、还有餐饮店、还要卖咖啡。
如果说来一个业务就重头搞一套用户体系、订单体系、库存体系,最终的结果就是像矗立起来的一个个烟囱,也就是烟囱式架构。
烟囱的现象很普遍,大家各玩各的,先把业务跑起来再说,但是缺陷有很多。
首先,重复建设开发,不用说都能看出来,每次重头搞一套,不说开发成本,就说服务器和运维成本都够头疼的。
第二点,就是系统之间交互协作成本直线上升,业务发展了,可能要做一些精确营销活动,设计用户画像,对数据分析之类的啦,这都很正常。
哦豁,这时候你发现用户在好几个系统里,这个交互打通的成本就太高了。
要做个数据统计,还要调好几个系统接口,可能数据结构还不一样,搞都搞死你。
还有就是业务沉淀和发展,这也是后面要说的中台了。
难道这些系统之间就没有通用的能抽象的能力可以共用吗?
这也就是中台的发展的方向,抽象、沉淀和共用。
![e3cafcf23a8edc8a0a627881e7fbfc1a.png](https://i-blog.csdnimg.cn/blog_migrate/1eef227db41058abf16dcd7146aac655.png)
微服务架构
最后就是说到我们的微服务时代了,这个大家都很熟悉,不需要说太多东西。
至于现在还有Serverless、云原生什么低代码这里就不展开了,等后面的话有机会再说。
回到微服务的话题,微服务和SOA有什么区别。
个人认为其实很接近,微服务就是更加自由和更细粒度的SOA。
微服务没有那么多框架约束,我们想用啥用啥,虽然在SOA也可以实现,比如通信我们可以用Dubbo,可以用Feign,Thrift,GRPC,想用啥用啥。
举个例子用 spring cloud 来说,eureka可以帮我们做服务注册和发现,打个@enableEurekaClient就可以成为客户端连接到Eureka了。
路由直接用zuul,限流熔断用hystrix,负载均衡用ribbon,远程调用用feign。
非常方便,当然还可以选择用Spring Cloud Alibaba,这个我认为可能会是将来一段时间的趋势,更新维护的非常勤快。
Dubbo Nacos Sentinel这一套整起来明显更符合国内的使用习惯。
服务共享
说完架构的发展,可以回到我们之前的中台话题。
那其实中台的作用已经不言而喻了,就是共享。
以现在比较主流的一些电商来说,几个共享服务中心的划分。
![c4fc8ba657a7e21acdd2f89cc5946d41.png](https://i-blog.csdnimg.cn/blog_migrate/98ac3303607ec9aa8bcf881fce4ca8f0.png)
首先用户中心必不可少,用户是基础服务,用户中心集成用户通用的能力,包括注册登录,SSO单点登录,还要和大数据配合用户打标签,用户画像等。
营销中心这个也很重要,包含各种优惠活动、优惠券、红包、卡券、积分、会员等级、返佣之类的和营销相关的东西。
交易中心处理用户下订单,如果下单有返佣,积分之类的话,这个叫做履约,后面再说,关于交易中台是我后面要说的。
支付中心负责支付,退款,三方支付、银行对接、预算管控等等。
数据中心,这个其实和业务中台是两块方向,今天我要说的都是业务中台,针对业务系统的沉淀和共享,数据中台则是更偏向大数据方向的,不在这里赘述。
最底层服务是我们的基础设施和中间件的能力,比如数据库、消息服务Kafka、Rabbitmq、数仓、文件系统。
这张图画出来好像除了中台和前台没别的东西了,并不是这样,我只是想表达说共享服务是作为支撑上层业务的核心,下层还有后台的服务并没有画出来而已,也就是顺应着大中台、小前台的架构来说。
服务拆分
讲到这个服务抽象和共享就顺便说说服务拆分的原则,这个说法太多了,见仁见智,更多的是遵循原有的一些经验去做处理。
总的来说,现在我们主流的拆分都是根据业务角度去拆分。
高内聚、低耦合,这个没啥说的,所有的服务都应该遵循这个原则,否则你要拆那就是瞎几把拆。
高内聚说的是比如交易中台,只围绕交易相关的、依赖性非常高的进行拆分。
低耦合则是说不同的服务,业务之间要隔离,不要耦合在一起,但是这个得有过程。
举个例子来说一开始的业务没什么人,用户地址这些信息就放在用户的服务里,好像也没什么问题。
随着业务的发展,这个地址信息和物流的服务好像关联越来越大,是不是就可以拆到物流服务里。
所以,这个要用发展的眼光去看待问题,不能一刀切。
回头去个小公司,别人就几万用户,几个程序员,就一个服务,你非要干微服务,拆几十个服务出来,这就不对是不是。
数据完整性
其实也类似,业务相关数据一定要完整,比如你做拆分,拆分完了之后用户名字拆到别的系统里去了,那就不太合理了。
持续迭代
也就是说要可持续性地做架构升级的调整和拆分,这个还是要跟着业务的发展走,不能一下拆的太细,也不能一下子太粗。。
你能明白我的意思吧,我没有在开车。。
交易中台
说了好久,总算说到交易中台了,我之前干交易中台干了差不多两年时间,自认为还算比较了解,除了一些东西没有实现之外,由于公司发展和时间的关系。
交易中台上面也提到过,主要就是从用户看到商品,然后到订单确认页,最后下订单,支付,配送,签收,这样一个整个过程都是交易中台在做的事情。
交易的定义就是买卖双方对有价物品和服务进行互通有无的行为,可以是以货币为交易媒介的过程,也可以是以物易物。
而交易过程,现在一般都是分为订约和履约两个,这基本是所有的交易中台的规则了。
某某在什么时间做了什么事情,这是订约。
举个例子来说,买方给卖方提供了有价物品,比如钱,卖方需要给买方提供服务。
而履约的则是某某在约定的时间完成约定的事情,比如交付货币、物品或者服务。
整个流程大致就是这个样子,当然一般我们都会分为正向和逆向两个方向去处理,正向完成交易的过程,逆向你可以理解为取消、退款这个环节。
![a0eb47c1ff04f4bddc773004588cb520.png](https://i-blog.csdnimg.cn/blog_migrate/9ff13e42ff2c096d0e3f3c80731f8f83.png)
既然是中台,那么就要能适应各类的交易场景。
比如酒店行业你去预订房间,这是正向交易,最后你去入住、离店,这是你履约的过程。
供应链要采购,然后商家会发货,最后你签收,这也是订约和履约的过程。
点外卖也是同样的道理。
这些所有的场景,那么我们都可以用通用的流程来归纳起来,就是上面提到的通用的交易流程。
![49a9699bafe4326aeb8d1d4fef019c28.png](https://i-blog.csdnimg.cn/blog_migrate/ac8e0e7bf13cea51ef1d5915a320aa37.png)
抽象的概念说完了,需要再形象一点的来描述一下。
上面我们说到了一些现在比较常见的服务拆分和服务的划分,下面根据实际场景看看我们服务到底是怎么划分的。
这张图是美团的订单确认页,一般也叫做提单页。图太长,我拆分为3个小图来描述。
可以一起来分析一下这个页面应该由哪些服务来构成,由谁来聚合这么多服务的接口?
![25c3853f4308c6716ce7fa49008185d2.png](https://i-blog.csdnimg.cn/blog_migrate/a4ab633a36e3ffec208c7952c4d98da3.png)
首先地址信息上面也提到过了, 这个由用户服务或者说是物流服务来提供比较合适。
那配送时间这方面就应该由物流的算法来提供,他们会根据运力、天气、骑手一堆信息来计算一个比较合理的送达时间。
![bd2d219f674cf71493b1d22b973f09f9.png](https://i-blog.csdnimg.cn/blog_migrate/e539b96c6e0cb7b9ccc9c5b90dbd040f.png)
中间这一部分商品的详细信息肯定由商品服务来提供。
至于配送费啊、各种补贴、红包优惠券是不是该由营销来提供,这里其实会很复杂, 因为要计算各种条件的价格,计算出最终应该支付的金额,这个一般我们会由价格服务来输出。
![de421da9a75aa9a2bd80aff07b5e877b.png](https://i-blog.csdnimg.cn/blog_migrate/4fa5203e97de00debdade5236fc8b32e.png)
最下面这一部分叫做搭售,可以在下单的同时去购买会员,这个其实就相当于下了两个订单,一单是外卖单,另外一个订单就是搭售订单,购买会员的订单,最终两个订单合并支付,保持最终一致性就行了,下单成功,同时会员购买成功。
最终下单成功之后发送消息,物流团队根据消息去履约配送,营销根据下单消息该送积分、送红包就怎么送,另外如果有搭售会员的话,还需要进行会员升级,这也是属于履约的一部分。
这个地方还有两个挺有意思的点。
第一个是扣库存的问题,应该是下单成功扣库存,还是支付成功扣库存(不用太考虑保存订单和扣库存分布式事务的问题,这个会保证最终一致性)。
一般所有的业务都会下单就扣库存,但是这样会有一个问题。
之前我们做活动,会把很多房间拿出来做优惠活动,单价就会便宜,但是库存有限,这个叫做尾房甩卖。
很多黄牛就先去下单把库存占住,然后再卖给用户,马上取消订单,帮用户下单。
所以我们之前有两种模式,针对这种类型的特殊情况会支付成功后才扣库存,普通模式像电商外卖一般没这种问题,都是下单就扣。
还有一个就是这个券的问题,不知道大家发现了没有,买了会员送券,可以立刻使用,下面还标注了,本单可用。
你肯定能想到这个问题,一般我们是券发给用户了才能用,这里下单成功后发消息->履约->发券,这个券都还没有怎么提前用。
这又是一个交易系统里比较常见的,早两年应该是没有这个玩法的,也算是一个优化,一般会叫做虚拟券。
下单的时候去核销优惠券,一般会给营销传一个特殊的标记和参数,营销根据这个判断做特殊的处理,至于具体的逻辑,我也不是很清楚,搞的挺复杂的就是了。
再结合全景图看一下就清晰了和架构图看一下就清晰多了。
<<< 左右滑动见更多 >>>
金融中台
金融中台不够纯粹,与其说是中台,不如说是事业部更合适一点,一般现在国内很多公司的金融中台基本都逃脱不了这几块的内容,很多都非常类似,就是根据不同的业务有点出入而已。
![bd3aff5af3346b68b4a76a097506eb51.png](https://i-blog.csdnimg.cn/blog_migrate/03aac19c9c8afd855884953e873cc6da.png)
支付是整个金融中台的核心,跳转的统一收银台又是支付的核心。
清结算也很核心,非常重要,这个我也干过一段时间,预算,活动、券这是营销的角度,预算则是财务金融的角度。
一般创建活动的时候一定要申请预算,活动创建设置库存数量,同时申请财务预算,一般情况都是1:1,创建成功不可以修改,库存可以临时改,但是预算改不了,除非重新申请。
金融中台自己领会好吧。
去中台化
这一段我不能放,涉及到一些公司隐私的东西,但是可以聊聊其他的。
比如开发流程,就我经历过的,中台这种部门一旦起来了,很容易一家独大,话语权太强,并且对于稳定性的要求太高,一定程度上阻碍了业务的开发。
其次对于业务的支撑和快速发展,其实可能没有想象中的那么好,经历过的大家应该也都会有体会的。
再者,中台这种产品必然涉及了太多的政治层面的博弈,我觉得SuperCell那种小公司玩得转确实可以,但是体量太大的公司玩的好挺难的,那体量不大的公司又没有太大必要搞什么鬼中台,你又不是啥游戏公司对不对,毕竟还是互联网公司为主,做业务开发为主。
好了,言尽于此吧,大家88,我是艾小仙,我们下期见,最近会不间歇性的保持周更的节奏,阅读掉的有点狠,大家加把劲帮忙点赞转发一些,感激不尽。
文章内容参考的书是凤凰架构,邹老师写的,没有买实体书的同学可以看看电子版的:http://icyfenix.cn/introduction/about-me.html
另外一些是之前公司内部的PPT我修改的,还有一些记录的是参考的好像阿里的一本啥书,之前看过记录的一点东西,现在有点记不起来了。