公司内做的一个简略的分享，文章内容是我依据本人讲的还有录像又手撸了一遍，累。

明天给大家分享一下对于架构和中台的一些货色。

次要会介绍一下中台的起源，这个大家可能都比较清楚，网上的文章和视频啊一大堆。

还有就是对于架构的倒退过程不得不在两头阐明一下，由此引申进去中台的诞生。

最初会就对于交易中台和金融中台做一个介绍，因为我最近两年在其余公司做的一个是交易中台，还有一个就是金融中台相干的业务。

中台由来

首先，来看一下中台的由来。

中台的起源次要是阿里，他们在 15 年访问在芬兰的一家游戏公司，也就是 SuperCell。

这家公司十分牛逼，号称是世界上最胜利的的移动游戏公司，做出的游戏也十分有名，必定很多人也玩过。

比方部落和平、海岛奇兵等等。

我也玩过一下他们的那个游戏，不过感觉没啥意思。

这家公司的规模只有不到 200 人，公司的开发模式通常都会由 2 - 7 集体的小团队进行开发，这个在他们外部叫做 cell，这也是他们公司名字的由来。

开发过程通常是团队外部决定，而后用最快的工夫开发出测试版本，如果受欢迎就持续干，否则的话就迅速放弃。

产品失败之后，不光不会受到惩办，他们还会搞个 party 来庆贺，庆贺本人学到了新的货色。

不过我感觉挺奇葩的，要是都依照他们这个模式来，晚期腾讯、阿里这些大公司都该死绝了。

咱们都晓得，腾讯晚期的时候想卖 100 万都没人要，马总切实没辙才只能硬着头皮持续做上来。

然而，就是这样一家小公司，2015 年的净利润达到了 15 亿美元，而且在 2016 年的时候被腾讯 86 亿美元收买。

这些都不是重点哈，重点咱们明天要讲的是他们的开发模式，为什么能疾速开发一个新游戏进去？

原本在咱们设想中，开发一个新的游戏是一个很消耗工夫精力的货色，几周开发一个还不错的游戏应该是很有难度的事件。

重点就在于他们的”中台“，也是他们多年游戏积淀下来的货色。

他们在后面的很多年工夫里对通用的游戏素材、算法等等做了很多积淀。

这也就是前面马云回来阿里之后鼎力搞的中台了。

聊聊架构

讲完中台的来历，在将中台之前，咱们还是要先说说架构的倒退过程。

单体架构的时代

在我刚刚下班的时候，大略是 11 年、12 年基本上我接触到的我的项目都是这个样子。

一个团队的所有货色都在一块，什么用户注册登录、领取啊、订单都在一起，常常是改一个小东西一个大我的项目都要跟着公布。

个别单体的架构都是 单过程 的，这也是针对咱们当初的微服务来说的，就是打个 jar 包或者 war 包上传就完事儿了，所有模块都在一个过程里，如果要降级或者重启，那整个应用服务都要重启。

当然了，简略的我的项目划分模块分层还是有的，比方咱们那时候罕用的 MVC 模式。

简略是很简略，然而同样毛病也是很显著的。

第一点就是团队协同单干的老本高，如果说小公司没几个人还好，一旦业务疾速倒退起来，代码量感人，刚开始下班那会儿我的电脑常常就只能跑的动一个我的项目，不过如同也没有别的我的项目了。

常常改一个简略的货色可能到处是抵触，更不要说一个大服务的发版问题。

第二点，我的项目太简单了，什么货色都是大杂烩，全在外面。

第三点，数据库连贯的问题，一个服务太大了，就一个数据库的集群，业务越来越多，服务器越来越多，到前面单机可能只搞个个位数的连贯都要不够用了。

所以，个别随同拆分服务，数据库也会做拆分，独立的服务领有独立的数据库。

最初一点，拓展性的问题，所有的性能都在一个服务里，可能理论状况是某几个功能模块负载十分高，比方订单或者库存的服务，频繁的读写，这时候想要扩大很难搞。

更重大的问题就是，如果一个模块出了问题，整个利用都不能用了。

这时候没有方法了，只能拆分。

因而就到了咱们第二个架构模式，SOA 的时代。

SOA(Service-Oriented Architecture)

我在饿了么工作那会儿，外面就有一大堆的 SOA 的称说，并且始终都是。

SOA 是什么意思呢，全名是这个Service-Oriented Architecture，意思就是面向服务的架构，基本上和咱们当初的微服务差不多一样。

SOA 的外围在于：松耦合和服务重用，当单体架构呈现瓶颈的时候，首先想到的都是拆，SOA 时代的话，其实也曾经就有了服务注册发现、服务治理这些概念了，和微服务能够说从认知上没有任何区别。

SOA 其实有两种模式，一种是中心化，一种是去中心化，下图中示意的就是中心化的服务调用形式。

服务调用之间都通过 ESB 服务总线，调用方之间屏蔽了接口的批改，ESB 要做服务申请路由、数据格式转换，各种 HTTP SOCKET 适配和接入，所有脏活累活都归他干了。

这样很显著的看进去问题了。

第一个就是申请，同样的申请次数是通常去中心化的 2 倍，原本 A 调用 B，当初要通过 ESB。

第二个是肉眼可见的问题，这个 ESB 的压力会十分大，能够通过集群解决，然而 ESB 的性能瓶颈会导致所有服务的瓶颈。

然而，这个模式在当初十分受欢迎，次要起因是什么呢？

就是 烟囱式架构 引发进去的问题。

烟囱式架构是什么？

就像这张图形容的，你有好几个业务，因为工夫或者说团队、公司各种起因，搞成了好几套独立的服务，开发和运维都没啥关系，大多数公司之前的倒退过程中都会存在这样的问题。

比方我之前的公司先做酒店业务、而后又有外卖、还有餐饮店、还要卖咖啡。

如果说来一个业务就重头搞一套用户体系、订单体系、库存体系，最终的后果就是像矗立起来的一个个烟囱，也就是烟囱式架构。

烟囱的景象很广泛，大家各玩各的，先把业务跑起来再说，然而缺点有很多。

首先，反复建设开发，不用说都能看进去，每次重头搞一套，不说开发成本，就说服务器和运维老本都够头疼的。

第二点，就是零碎之间交互合作老本直线回升，业务倒退了，可能要做一些准确营销流动，设计用户画像，对数据分析之类的啦，这都很失常。

哦豁，这时候你发现用户在好几个零碎里，这个交互买通的老本就太高了。

要做个数据统计，还要调好几个零碎接口，可能数据结构还不一样，搞都搞死你。

还有就是业务积淀和倒退，这也是前面要说的中台了。

难道这些零碎之间就没有通用的能形象的能力能够共用吗？

这也就是中台的倒退的方向，形象、积淀和共用。

微服务架构

最初就是说到咱们的微服务时代了，这个大家都很相熟，不须要说太多货色。

至于当初还有 Serverless、云原生什么低代码这里就不开展了，等前面的话有机会再说。

回到微服务的话题，微服务和 SOA 有什么区别。

集体认为其实很靠近，微服务就是更加自在和更细粒度的 SOA。

微服务没有那么多框架束缚，咱们想用啥用啥，尽管在 SOA 也能够实现，比方通信咱们能够用 Dubbo，能够用 Feign，Thrift，GRPC，想用啥用啥。

举个例子用 spring cloud 来说，eureka 能够帮咱们做服务注册和发现，打个 @enableEurekaClient 就能够成为客户端连贯到 Eureka 了。

路由间接用 zuul，限流熔断用 hystrix，负载平衡用 ribbon，近程调用用 feign。

十分不便，当然还能够抉择用 Spring Cloud Alibaba，这个我认为可能会是未来一段时间的趋势，更新保护的十分勤快。

Dubbo Nacos Sentinel 这一套整起来显著更合乎国内的应用习惯。

服务共享

说完架构的倒退，能够回到咱们之前的中台话题。

那其实中台的作用曾经显而易见了，就是共享。

以当初比拟支流的一些电商来说，几个共享服务中心的划分。

首先用户核心必不可少，用户是根底服务，用户核心集成用户通用的能力，包含注册登录，SSO 单点登录，还要和大数据配合用户打标签，用户画像等。

营销中心这个也很重要，蕴含各种优惠活动、优惠券、红包、卡券、积分、会员等级、返佣之类的和营销相干的货色。

交易中心解决用户下订单，如果下单有返佣，积分之类的话，这个叫做履约，前面再说，对于交易中台是我前面要说的。

领取核心负责领取，退款，三方领取、银行对接、估算管控等等。

数据中心，这个其实和业务中台是两块方向，明天我要说的都是业务中台，针对业务零碎的积淀和共享，数据中台则是更偏差大数据方向的，不在这里赘述。

最底层服务是咱们的基础设施和中间件的能力，比方数据库、音讯服务 Kafka、Rabbitmq、数仓、文件系统。

这张图画进去如同除了中台和前台没别的货色了，并不是这样，我只是想表白说共享服务是作为撑持下层业务的外围，上层还有后盾的服务并没有画进去而已，也就是适应着大中台、小前台的架构来说。

服务拆分

讲到这个服务形象和共享就顺便说说服务拆分的准则，这个说法太多了，见仁见智，更多的是遵循原有的一些教训去做解决。

总的来说，当初咱们支流的拆分都是依据业务角度去拆分。

高内聚、低耦合，这个没啥说的，所有的服务都应该遵循这个准则，否则你要拆那就是瞎几把拆。

高内聚说的是比方交易中台，只围绕交易相干的、依赖性十分高的进行拆分。

低耦合则是说不同的服务，业务之间要隔离，不要耦合在一起，然而这个得有过程。

举个例子来说一开始的业务没什么人，用户地址这些信息就放在用户的服务里，如同也没什么问题。

随着业务的倒退，这个地址信息和物流的服务如同关联越来越大，是不是就能够拆到物流服务里。

所以，这个要用倒退的眼光去对待问题，不能一刀切。

回头去个小公司，他人就几万用户，几个程序员，就一个服务，你非要干微服务，拆几十个服务进去，这就不对是不是。

数据完整性

其实也相似，业务相干数据肯定要残缺，比方你做拆分，拆分完了之后用户名字拆到别的零碎里去了，那就不太正当了。

继续迭代

也就是说要可持续性地做架构降级的调整和拆分，这个还是要跟着业务的倒退走，不能一下拆的太细，也不能一下子太粗。。

你能明确我的意思吧，我没有在开车。。

交易中台

说了良久，总算说到交易中台了，我之前干交易中台干了差不多两年工夫，自认为还算比拟理解，除了一些货色没有实现之外，因为公司倒退和工夫的关系。

交易中台下面也提到过，次要就是从用户看到商品，而后到订单确认页，最初下订单，领取，配送，签收，这样一个整个过程都是交易中台在做的事件。

交易的定义就是 买卖双方对有价物品和服务进行互通有无的行为，能够是以货币为交易媒介的过程，也能够是以物易物。

而交易过程，当初个别都是分为 订约 和履约 两个，这根本是所有的交易中台的规定了。

某某在什么工夫做了什么事件，这是订约。

举个例子来说，买方给卖方提供了 有价物品 ，比方钱，卖方须要给买方提供 服务。

而履约的则是某某在约定的工夫实现约定的事件，比方交付货币、物品或者服务。

整个流程大抵就是这个样子，当然个别咱们都会分为正向和逆向两个方向去解决，正向实现交易的过程，逆向你能够了解为勾销、退款这个环节。

既然是中台，那么就要能适应各类的交易场景。

比方酒店行业你去预订房间，这是正向交易，最初你去入住、离店，这是你履约的过程。

供应链要洽购，而后商家会发货，最初你签收，这也是订约和履约的过程。

点外卖也是同样的情理。

这些所有的场景，那么咱们都能够用通用的流程来归纳起来，就是下面提到的通用的交易流程。

形象的概念说完了，须要再形象一点的来形容一下。

下面咱们说到了一些当初比拟常见的服务拆分和服务的划分，上面依据理论场景看看咱们服务到底是怎么划分的。

这张图是美团的订单确认页，个别也叫做提单页。图太长，我拆分为 3 个小图来形容。

能够一起来剖析一下这个页面应该由哪些服务来形成，由谁来聚合这么多服务的接口？

首先地址信息下面也提到过了，这个由用户服务或者说是物流服务来提供比拟适合。

那配送工夫这方面就应该由物流的算法来提供，他们会依据运力、天气、骑手一堆信息来计算一个比拟正当的送达工夫。

两头这一部分商品的详细信息必定由商品服务来提供。

至于配送费啊、各种补贴、红包优惠券是不是该由营销来提供，这里其实会很简单，因为要计算各种条件的价格，计算出最终应该领取的金额，这个个别咱们会由价格服务来输入。

最上面这一部分叫做搭售，能够在下单的同时去购买会员，这个其实就相当于下了两个订单，一单是外卖单，另外一个订单就是搭售订单，购买会员的订单，最终两个订单合并领取，放弃最终一致性就行了，下单胜利，同时会员购买胜利。

最终下单胜利之后发送音讯，物流团队依据音讯去履约配送，营销依据下单音讯该送积分、送红包就怎么送，另外如果有搭售会员的话，还须要进行会员降级，这也是属于履约的一部分。

这个中央还有两个挺有意思的点。

第一个是扣库存的问题，应该是下单胜利扣库存，还是领取胜利扣库存（不必太思考保留订单和扣库存分布式事务的问题，这个会保障最终一致性）。

个别所有的业务都会下单就扣库存，然而这样会有一个问题。

之前咱们做流动，会把很多房间拿进去做优惠活动，单价就会便宜，然而库存无限，这个叫做尾房甩卖。

很多黄牛就先去下单把库存占住，而后再卖给用户，马上勾销订单，帮用户下单。

所以咱们之前有两种模式，针对这种类型的非凡状况会领取胜利后才扣库存，一般模式像电商外卖个别没这种问题，都是下单就扣。

还有一个就是这个券的问题，不晓得大家发现了没有，买了会员送券，能够立即应用，上面还标注了，本单可用。

你必定能想到这个问题，个别咱们是券发给用户了能力用，这里下单胜利后发音讯 -> 履约 -> 发券，这个券都还没有怎么提前用。

这又是一个交易系统里比拟常见的，早两年应该是没有这个玩法的，也算是一个优化，个别会叫做虚构券。

下单的时候去核销优惠券，个别会给营销传一个非凡的标记和参数，营销依据这个判断做非凡的解决，至于具体的逻辑，我也不是很分明，搞的挺简单的就是了。

再联合全景图看一下就清晰了和架构图看一下就清晰多了。

<,>

金融中台

金融中台不够纯正，与其说是中台，不如说是事业部更适合一点，个别当初国内很多公司的金融中台根本都逃脱不了这几块的内容，很多都十分相似，就是依据不同的业务有点出入而已。

领取是整个金融中台的外围，跳转的对立收银台又是领取的外围。

清结算也很外围，十分重要，这个我也干过一段时间，估算，流动、券这是营销的角度，估算则是财务金融的角度。

个别创建活动的时候肯定要申请估算，流动创立设置库存数量，同时申请财务预算，个别状况都是 1：1，创立胜利不能够批改，库存能够长期改，然而估算改不了，除非从新申请。

金融中台本人体会好吧。

去中台化

这一段我不能放，波及到一些公司隐衷的货色，然而能够聊聊其余的。

比方开发流程，就我经验过的，中台这种部门一旦起来了，很容易一家独大，话语权太强，并且对于稳定性的要求太高，肯定水平上妨碍了业务的开发。

其次对于业务的撑持和疾速倒退，其实可能没有设想中的那么好，经验过的大家应该也都会有领会的。

再者，中台这种产品必然波及了太多的政治层面的博弈，我感觉 SuperCell 那种小公司玩得转的确能够，然而体量太大的公司玩的好挺难的，那体量不大的公司又没有太大必要搞什么鬼中台，你又不是啥游戏公司对不对，毕竟还是互联网公司为主，做业务开发为主。

好了，言尽于此吧，大家 88，我是艾小仙，咱们下期见，最近会不间歇性的放弃周更的节奏，浏览掉的有点狠，大家加把劲帮忙点赞转发一些，感激不尽。

文章内容参考的书是凤凰架构，邹老师写的，没有买实体书的同学能够看看电子版的：http://icyfenix.cn/introducti…

另外一些是之前公司外部的 PPT 我批改的，还有一些记录的是参考的如同阿里的一本啥书，之前看过记录的一点货色，当初有点记不起来了。