SOA的核心内容是ESB，全称是EnterpriseServiceBus，SOA通过ESB将企业中各个不同的异构服务连接在一起，是SOA架构的核心，但是SOA架构是成也ESB，败也ESB。
ESB的目的是松耦合马也就是减少各个服务间的依赖和互相影响，但是随着服务越来越多，ESB自身的问题也逐渐显现，例如逻辑臃肿、性能低下、扩展困难等
2、微服务：
微服务的三哥重要特点就是：1、将系统拆分为Small服务；2、服务之间通过轻量级机制通信，例如HTTP；3、服务能够快速自动化的部署
下图是从服务粒度、服务通信、服务交付、应用场景和技术本质五个角度对比SOA与微服务的差别。
目前SOA和微服务并非其中一家独大，在传统行业中，由于历史原因，系统多是外包出去，导致各种语言、协议非常杂乱，同时由于自身开发能力较弱，因此用SOA较多，而在花联网公司，系统大多数是自建系统，其自身开发能力较强，因此采用微服务较多。
3、可扩展架构
（1）分层架构与微服务
分层架构是端到端的架构或者单个系统的内部架构，按照某种规则划分为不同层级，例如按照业务划分的端到端架构、按照客户端/服务端划分的B/S或C/S架构、按照J2EE架构分层划分的四层架构
（2）微服务与分层架构
在分层架构中，微服务一般是端到端分层架构中的业务层的架构，一般不会用于其他的层，因为微服务一般就是用来实现业务可扩展的架构。
5、整洁架构与微服务
Bob大叔在其《架构整洁之道》中提出的整洁架构，最内层的Entities可以理解为领域模型，然后外面一层是UseCases，可以理解为业务逻辑，在外面一层是Controller，其负责对接接口，包括对Web的接口、对UI的接口、对DB的接口等等，最外层就是各种DB、设备等等
整洁架构和微服务的关系：单个微服务内部可以使用整洁架构，但是不能说整个架构是整洁架构，只能说整个架构是微服务架构，而单个微服务是整洁架构。
6、微内核架构与微服务
微内核架构（MicrokernelArchitecture），也被称为插件化架构（Plug-inArchitecture）,是一种面向功能进行拆分的可扩展性架构。微内核架构主要包含两个组成部分：核心系统（coresystem）和插件模块（plug-inmodules）。
核心系统负责和具体业务功能无关的通用功能，例如模块加载、模块间通信等；插件模块负责实现具体的业务逻辑，具体的业务处理功能需要具体的插件处理
微内核架构和微服务的关系：单个微服务可以使用微内核架构，例如在日常落地时，常见的微内核架构有风控、营销、工作流等场景
微服务架构的陷阱主要是由于微服务拆分太细或者基础设施缺乏导致的，力度太细会影响服务关系、团队效率和问题定位，而基础设施缺乏会导致无法快速交付和服务管理混乱的问题。
1、拆分粒度太细，服务关系复杂
需求分析、方案设计、测试、部署……难度都会增加。例如：
（1）分布式服务如何保证数据一致性；
（2）分析设计的时候需要考虑的影响点变多。
服务拆分太细实际上是降低了服务内部的复杂度，但是增大了外部复杂度。
2、拆分粒度太细，团队效率下降
需求分析、方案设计、测试、部署……工作量都会增加。例如：
（1）接口设计数量，1次请求由两个服务处理，接口数量1个，5个服务处理，接口数量4个，接口设计、接口联调、接口测试等工作量都会大大增加；
（2）某个业务功能上线，需要升级的系统数量会增加。粗粒度服务
3、拆分粒度太细，问题定位困难
单个微服务的故障，会导致多个微服务异常，监控系统一片红，到处都在告警，但是不知道根因。
4、拆分粒度太细，系统性能下降
调用链越长，单次请求耗时会更长。
5、缺乏基础设施，无法快速交付
（1）没有自动化测试支撑，每次测试时需要测试大量接口；
（2）没有自动化部署支撑，人肉运维，手都敲麻了；
（3）没有自动化监控，每次故障定位都需要人工查几十台机器几百个微服务的各种状态和各种日志文件。
6、缺乏基础设施，服务管理混乱
（1）服务路由：假设某个微服务有60个节点，部署在20台机器上，那么其他依赖的微服务如何知道这个部署情况
（2）服务故障隔离：假设上述例子中的60个节点有5个节点发生故障了，依赖的微服务如何处理这种情况
（3）服务注册和发现：同样是上述的例子，现在我们决定从60个节点扩容到80个节点，或者将60个节点缩减为40个节点，如何让依赖的服务知道新增或者减少的节点
上述的六大陷阱主要是因为服务拆分太细和基础设施缺乏导致，那么解决方法也就呼之欲出，就是合理的拆分微服务和完善基础设施，在下面第三、四部分会详细描述如何完善基础设施和合理的拆分微服务。
微服务拆分会涉及数据库拆分和服务拆分，拆分后数据存在不同的库中，接口存在于不同的服务中，就会产生数据分布和服务分布的问题：
数据分布是由于数据分不到不同的库表中，原来单体服务数据在同一个库中，可以使用数据库的事务保证数据的一致性，但是分布在多个库中，就需要使用分布式事务来解决，在使用分布式事务时，有可能会失败重试，那么就需要做好幂等处理
服务分布是由于接口存在于不同的微服务中，有个能当前接口升级，但是有多个服务在调用，有的要用新接口，有的需要使用老接口，如何做接口兼容是个问题，另外由于接口在多个服务上，有可能发生循环调用的问题。
数据分布的解决一般会基于BASE理论做最终一致性处理：
BASE：BasicallyAvailable（基本可用）、SoftState（软状态）和EventuallyConsistent（最终一致性）。
核心思想：分布式系统由于CAP理论限制，无法做到强一致性，但每个应用都可以根据自身业务特点，采用适当的方式来使系统达到最终一致性。
设计关键：1.适当的方式：有哪些方式？分布式系统只有一种方式：消息。区别只是传递消息的方式和消息内容的不同，例如消息队列、接口调用、ZooKeeper事件。
1、分布式事务
（1）业务级分布式事务-本地事务消息
（2）业务级分布式事务-消息队列事务消息
（3）业务级分布式事务-TCC
2、全局幂等
分布式数据只能通过消息来实现最终一致性，而消息可能会丢失，因此需要重试，重试就需要保证幂等。
在保证幂等时，有可能不同服务发出相同的数据，在业务上可能是两条数据，这种也是需要做幂等处理的，因此，一般会使用全局幂等，保证每个幂等操作都是全局唯一的。
全局幂等的处理思路有：全局唯一ID和状态机，全局唯一ID一般用于增删操作，而状态机一般用于更新操作。
3、接口兼容
接口兼容是指某个微服务的某些接口升级，依赖这些接口的微服务不一定能够全部同时升级。解决方案：
（1）接口多版本，直接拷贝一份旧接口代码，在旧接口代码上修改，接口URL加上v1/v2这种标识；
（2）接口逻辑兼容，同一份接口代码，兼容新旧逻辑，容易互相影响，且旧接口下线时又要修改代码（不推荐）。
4、接口循环调用
这种几乎没有好的解决方案，运气好靠测试发现，运气不好靠上线发现。
微服务基础设施架构包括服务接入层、服务运行层、技术支撑层、基础设施层，按照优先级排序，服务运行层、服务接入层、基础设施层、技术支撑层，因为对微服务系统来说，服务注册、服务发现、服务路由、服务容错是其基础和灵魂，其余的几个一般都是等服务量级达到一定规模之后才会需要，因此在做基础设施搭建时，并非一定要把所有的基础设置搭建完毕，可以按照优先级逐步落地。
微服务基础设施中最核心的就是服务运行层的服务注册、服务发现、服务路由，其是微服务的灵魂所在，在具体落地时，可以使用嵌入SDK、反向代理、网络代理等方式来实现。
模式一：嵌入SDK
优点：1.架构简单，天然支持高性能、高可用；2.维护简单，无需维护独立的Proxy节点。
缺点：1.应用侵入，需要集成SDK，并联动升级；2.多语言重复开发SDK。
模式二：反向代理式
优点：1.应用无侵入；2.天然支持多语言。
缺点：1.ServiceProxy需要通过集群来做高性能、高可用；2.维护复杂，需要维护ServiceProxy集群。
模式三：网络代理式（ServiceMesh）
优点：1.应用无侵入；2.天然支持多语言；3.天然支持架构高性能、高可用。
缺点：1.维护复杂，需要维护每台服务器上的ServiceProxy；2.单台服务器的ServiceProxy是单点；3.全链路请求性能会下降，目前比较认可的性能下降在20%左右。
微服务框架模式对比：
1、嵌入式SDK样例-Dubbo
ApacheDubbo是一款高性能、轻量级的开源Java服务框架，提供了六大核心能力：1.面向接口代理的高性能RPC调用；2.智能容错和负载均衡；3.服务自动注册和发现；4.高度可扩展能力；5.运行期流量调度；6.可视化的服务治理与运维。
【出品方】阿里出品，2017年停更过，现在是Apache项目。
2、嵌入式SDK样例-SpringCloud
其提供了更完善的解决方案，除了服务注册、服务发现、服务路由等，还有熔断器、全局锁等等处理
3、反向代理式案例-APISIX
这是一款国产的开源软件，既可以实现南北流量又支持东西向流量，这里说明一下，通常我们在画架构图时，从客户端到服务端的流程都是从上到下的，这种叫做南北流量，而服务间的调用一般是从左到右的，这种叫做东西流量，由于其支持东西流量，因此其可以作为微服务间服务注册、服务发现、服务路由的选择。
4、ServiceMesh案例-Istio
目前Istio在ServiceMesh的解决方案中是一个统治地位的存在，其功能非常强大，例如可以做服务注册、服务发现、服务路由、监控、安全等。Istio主要分为控制面板和数据面板，数据面板就是流量的调度、请求、分发、路由等等，而控制面板主要是配置、服务发现、认证等等。
5、如何选择开源微服务框架（遇事不决Spring，选择太多Apache！）
在做微服务基础设施选型时，如果语言统一为Java，那么就看是否需要RPC框架，需要的话就选用Dubbo，不需要就选择Springcloud，如果为多语言，如果集群不大，则选用APISIX，超大集群则选用Istio，因为在特大集群规模下，Proxy方案下，proxy集群也会变的无比庞大，从而导致成本增大和维护困难，因此就算Istio有一定的性能损耗，在权衡各种问题后，还是会选择Istio。
1、微服务落地的总体思路
微服务落地主要从服务拆分方式、基础设施要求、落地方式三个方面。
一般情况下，对于微服务拆分的适用场景如下：
从0开始构建的业务系统：一般按照业务拆分微服务，一步到位，同时需要搭建完善的基础设置，但是会按照优先级逐步落地
单体架构拆分为微服务：一般也是按照业务拆分微服务，但是会逐步进行拆分，一般先从非核心业务开始拆分，同时也是需要搭建完善的基础设施，并按照优先级逐步落地。这里特别说明一下，一般是从非核心业务开始拆分，因为刚开始拆分可能回踩很多坑，或者拆分后发现拆分的不合理等问题，使用非核心业务可以很好的去做实验，有很多团队在实际落地微服务时，反而是先对核心服务做拆分，导致拆分后存在很大的问题。
粗粒度服务微服务化：一般按照质量进行拆分，但是会逐步进行拆分，对于基础设施，一般会采用重用的方式处理。
局部系统优化：一般按照质量拆分微服务逐步落地，并且会重用已有的基础设施
2、按业务拆分微服务的技巧
（1）DDD
按照业务拆分时，DDD是一个绕不过的话题，其主要可以分为战略设计和战术设计两步：
战略设计：1.确定领域，对应微服务的“子域”；2.限界上下文，对应微服务的“服务”。
战术设计：聚合根、实体、值对象：对应面向对象方法的对象；聚合根：核心的有状态对象；实体：有状态的对象；值对象：无状态的对象。
但是DDD却很难落地，核心问题是DDD告诉你限界上下文是什么，却没有告诉你如何划分，例如在为什么要把这两个聚合划在一个限界上下文中而不是分为两个限界上下文这种问题，特别是DDD的权威书籍中都没有明确的答案。例如下面摘抄的DDD权威书籍中的描述，分别表述了要么请业务专家来划分，要么和各团队间达成一致，要么在人数少的时候不划分也行，因此，DDD并没有明确的标准怎么划分界定上下文，从而导致其很难落地。
“业务部门或者工作组织的划分可以很好地标明模型边界的位置。你将倾向于为每个业务功能寻找至少一位业务专家。”——《领域驱动设计精粹》P21
“团队必须决定在哪里定义BOUNDEDCONTEXT，以及它们之间有什么样的关系。……事实上，这样的决策通常需要与外部团队达成一致。……在实践中，团队之间的行政关系往往决定了系统的集成方式。”——《领域驱动设计》P268
（2）实际项目中业务边界划分
实际项目中的业务边界划分，一般看有没有业务专家，有的话，就让业务专家来划分边界，如果没有，再看是否是全新的业务，如果不是，可以参考业界的现有实现，如果是全新业务，可以先粗粒度的划分边界再逐步演进。
（3）实际项目中如何做微服务拆分
做服务拆分是，首先按照业务边界映射成领域，再根据领域推导出微服务，在推导过程中，可以使用一对一、多对一、一对多的方式进行推导，例如：一对一就是一个领域对应一个微服务，比如订单域就对应订单服务，会员域就对应会员服务，商品域就对应商品服务；多对一就是多个领域对应一个微服务，例如商品域和库存域对应一个商品服务，一对多表示一个域对应多个微服务，例如可以把订单域分为订单生成、订单支付、订单物流多个微服务。
那么在推导过程中，应该选择哪种模式呢，或者哪种模式更好呢，实际上并没有说哪个更好，而是要根据自身的情况去拆分，一般情况下根据三个火枪手原则去拆分最为合理。
（4）服务拆分技巧-三个火枪手原则
定义：平均3个开发人员负责一个微服务。
剖析：1.为什么不是1个？因为没有备份，且一个人思维有局限。2.为什么不是2个？因为异常情况下剩余1个，压力会很大；2个人负责维护一个微服务，微服务复杂度偏低。3.为什么不是4个或者5个？如果4个或4个以上，每个人不一定能掌握单个服务所有细节。
技巧：1.微服务数量=服务端开发人数/3；2.3=1+2，1个有经验的(P7/P6+)，2个普通的(P5/P6)；3.处于维护期的服务，维护人员为2人。
三个火枪手案例：
那么对于领域推导微服务数量，就看实际的开发人数，如果开发人员多，就采用一对多，开发人员少，就采用多对一，如果开发人员人数刚好，就采用一对一。
（5）拆分方法
一对一服务映射：可以刚好一个领域对应一个微服务，例如订单域对应订单服务，会员域对应会员服务等
多对一服务映射：可以将多个领域合并为一个微服务，例如将订单域、库存域、财务域合并为交易服务，将店铺域、商品域合并为商品服务等
一对多服务映射：上面的一对一和多对一都比较好处理，而一对多服务拆分一般会按照业务流程拆分。
实际落地时，可以列出核心业务功能的处理流程，将流程中的处理步骤作为拆分的维度。例如以下三个案例，先将交易流程拆分为订单生成、订单支付、商家发货、确认收货、交易成功五个大步骤，然后再根据三个火枪手的原则来看要把哪些流程放到一个服务中。
方案1：拆分为5个
方案2：拆分为2个，下单（包含订单生成、订单支付）、物流（包含商家发货、确认收货、交易成功）。
方案3：拆分为3个，下单（包含订单生成、订单支付）、发货（包含商家发货）、收货（包含确认收货、交易成功）。
3.掌握按质量属性拆分微服务的技巧
按性能拆分：
方法：根据运维系统统计请求量排名前3的业务，将流量最大的业务以及强关联的业务拆分出来。
目的：降低业务互相影响程度，拆分后优化流量大的业务，提升性能降低成本
按业务重要程度拆分：
方法：将重要程度高的业务拆分出来，注意重要程度高不一定是流量大的。
目的：降低业务互相影响程度，拆分后提升重要程度高的业务的可用性。
按可用性拆分：
方法：将经常出问题的业务拆分出来。
目的：降低业务互相影响程度，拆分后有针对性的提升问题多的业务。
按稳定性拆分：
方法：将稳定的业务拆分出来。
目的：降低业务互相影响程度，拆分后有利于不断变化的业务快速迭代。
1、中台发展史
中台发展史，从下图可以看到，中台在国内从09年孕育、15年面世，再到18年集中爆发再到19年的泛滥，然后就是到20年的质疑和到21年之后的迷茫，那么后续中台究竟会怎么发展，现在也是处于一个比较迷茫的阶段。
2、共享架构
无共享架构-大烟囱架构：在原来的架构中，每个业务都有一整套的基础建设和应用，这就是典型的大烟囱架构。
共享架构模式1-IaaS架构：在大烟囱架构上复用OS、虚拟化、服务器、存储和网络，就组成了IaaS架构
共享架构模式2-PaaS架构：在IaaS的基础上再复用运行环境、中间件、DB等，就组成了PaaS架构，PaaS架构只有应用和数据是独立的，其余都是共享的。
共享架构模式3-SaaS架构：在PaaS架构的基础上，将应用和数据也进行复用，就组成了SaaS架构
共享架构模式4-中台架构：而中台架构跟上面的三种共享架构还不一样，中台架构可以分为共享业务和共享数据，而根据这两种划分，不同的业务只处理自己特性的业务和数据即可。
3、中台的定义
下面是一些对于中台的定义：
中台就是“企业级的能力复用平台”。——Thoughtworks首席咨询师王健
中台是将系统的通用化能力进行打包整合，通过接口的形式赋能到外部系统，从而达到快速支持业务发展的目的。——百度百科
中台架构，是将企业的核心能力随着业务不断发展以数字化形式沉淀到平台，形成以服务为中心，由业务中台和数据中台构建起数据闭环运转的运营体系，供企业更高效的进行业务探索和创新,实现以数字化资产的形态构建企业核心差异化竞争力。——阿里官方定义
上面三种定义到底哪一个是正确的呢，这个不好说，因为中台可以分为业务中台和数据中台，想要很好的理解中台，就需要从两个维度分别阐述，如果放在一起解释，无论怎么解释都有可能有点片面
（1）理解中台概念-业务中台（针对相似业务）
业务中台总的来说是将企业内多个相似业务的通用业务能力沉淀到平台，以减少重复建设，提升业务开发效率的一种架构模式。
IaaS、PaaS、SaaS都不是中台
（2）理解中台概念-数据中台（针对所有业务）
数据中台应该是支持所有业务的，其核心是数据打通和数据复用。数据打通指的是业务间的数据需要打通，例如通过“统一用户ID”来关联同一用户在多个业务上的数据；数据复用指的是不同业务间的数据可以复用，提升整体的运营效率，例如：美团可能根据你看电影的数据来向你推荐外卖的商品。
数据中台总的来说是将企业所有业务的数据沉淀到同一平台，支持业务间数据打通以及数据复用，提升企业运营效率的一种架构模式。
（3）中台的价值：
业务中台：相似业务的能力共享，避免大量重复开发，提升开发效率。
业务相似度越高，业务中台价值越大，建议相似度达到60%以上的多个业务共建中台，例如“快车+专车”，“淘宝+天猫+咸鱼”，”火山+抖音+西瓜“。
评估业务相似度，需要依赖业务专家，而不是一个单纯的技术工作。
强行将相似度低的业务塞进一个中台，不但不会提升开发效率，还会大大降低效率。
数据中台：数据打通和复用，避免数据孤岛，提升运营效率。
使用数据中台的业务越多，数据中台价值越大。
数据中台的价值体现在：统一数据平台、跨业务的数据打通、跨业务的数据复用（挖掘）。
在中台建设中，常见的三个问题就是小业务抱中台大腿，中台抱大业务大腿；中台与业务边界那已明确、中台全流程效率并不高这三点。
1、小业务抱中台大腿，中台抱大业务大腿。
如上图所示，业务A非常强大，属于爸爸级别的业务，是中台KPI关键，那么中台肯定会首先抱业务A的大腿，再例如业务C，也是一个强大的业务，属于保高绩效冲击更高绩效的抓手，再例如业务X，有P11大佬站台的业务，是中台汇报的重点，那么也会重点做，至于其他的业务，中台有可能爱理不理，没事做就支持一下。
对于这一现象，目前没有看到很好的应对方法，中台建设最后就是一个组织结构问题（康威定律）。
2、中台与业务的边界难以明确
中台和业务的边界没有任何明确的规则，都是靠人肉讨论，在已有业务基础上比较容易提炼，创新业务几乎无法判断，同时因为创新业务对中台KPI没有帮助，大部分情况下都会被拒掉，由业务自己实现。因此可以看到中台适合做“组合式创新”，没法做“颠覆式创新”。
这种问题业务上和组织上目前没有很好的解决方法，技术上可以采用后面的技巧来缓解问题。
3、中台的全流程效率并不高
在中台支持业务落地时，每个业务功能都要讨论边界，同时每个业务功能都要考虑对所有业务的影响，一个很小的需求变动都可能需要几十人参与讨论，如果是稍微大一点的需求，有可能需要上百人参与讨论，因此效率并不会很高
这个问题业务上没有什么解决方法，技术上可以通过后面的技巧来缓解问题。
中台落地时，肯定都是采用微服务搭建业务中台：微服务不一定是中台，中台一定是微服务
1、Pipeline落地中台
在实际落地时，可以使用Pipeline封装不同业务流程，如下面钱包的案例，香港钱包只有解码、校验、路由的处理，而澳门钱包有解码、校验、码补充、路由四部分组成，在实际落地时，可以采用Pipeline进行封装。
Pipeline代码示例
2、用SPI封装不同业务
SPI全称ServiceProviderInterface，是Java提供的一套用来被第三方实现或者扩展的接口，它可以用来启用框架扩展和替换组件。SPI的作用就是为这些被扩展的API寻找服务实现。
还是用上面钱包的案例，设计出解码、校验、码补充、路由四个接口，不同的业务针对接口做不通的实现，然后中台使用SPI进行封装
3、Pipeline和SPI方案对比
下图是Pipeline和SPI的一个对比，Pipeline实现中，中台团队负责框架和实际的业务代码逻辑，该实现需要中台需要全部搞定，开发难度低，并且由于代码都在中台，因此直接统一部署，并且在业务和代码层面都做了隔离；而SPI实现中，中台团队主要负责框架的设计，具体的业务实现由业务团队负责，因此业务团队需要非常熟悉中台团队的设计和原理，并且边界要非常明确，开发难度高，在实际落地时，业务代码更新只需要发布jar包即可，这种实现方案是采用为微内核+插件的方式做了业务隔离和插件隔离。
在下面的对比图中，从开发模式、开发难度、业务隔离三个维度来说，都是SPI方案会更好一些，但是实际上在落地时，由于开发难度的问题，Pipeline采用的反而更多。
1、手游交易业务介绍
手游业务的交易类型可以分为寄售交易、担保交易、求购交易、自助交易几类。
【求购交易】：是指买家想要求购某些商品时，交易平台为买家提供一个平台发布求购信息，同时买家将求购资金存放在交易平台，卖家根据买家发布的求购信息，找到合适的商品后承接交易的一种全新交易模式。
【自助交易】：是指类似于淘宝交易的一种交易方式，由买家和卖家自行交易，交易平台仅提供一个商品发布和购买的平台，不参与交易过程。陪练、代练、陪玩用常用此类。
2、手游交易服务当时情况
单体架构，团队开发人员25人左右，开发周期和测试周期都比较长。
各种疑难问题很多，收集了一个问题Excel表格，大约100条。
每逢假期必出问题，性能扛不住，数据库撑不住。
爬虫经常导致系统挂掉。
3、问题分析及解决方案
微服务并不是所有问题的解决方案，需要根据具体的问题做具体的解决方案，例如上面的问题一一进行分析：
单体架构，团队开发人员25人左右，开发周期和测试周期都比较长。解决方案：这个没什么可说的，就是服务拆分，做微服务
各种疑难问题很多，收集了一个问题Excel表格，大约100条。解决方案：这个要看具体的问题点，例如有的是单一系统的问题，那么可以使用微服务拆分来解决，有的是因为不规范使用组件导致的，那么可以使用组件化，因此该问题的解决方案就是组件化+微服务
每逢假期必出问题，性能扛不住，数据库撑不住。解决方案：性能扛不住最快最有效的解决方案就是采用救火方案，例如加机器等，在后续要逐步的对性能做优化，因此该问题的解决方案就是救火+性能优化
爬虫经常导致系统挂掉。解决方案：冷热数据分离，读写分离
针对问题的分析和对应的解决方案，指定了三个阶段：
第一阶段：救火阶段，例如机器扩容、业务降级、立体化监控等
第二阶段：组件化阶段，例如缓存组件化、消息队列组件化、服务中心组件化等
第三阶段：解耦，也就是为服务拆分，例如将核心业务和非核心业务分离，组建业务中台，公共功能组件化等。
4、服务拆分方案
（1）微服务第1式-按业务重要程度拆分
可以按照业务的重要程度进行服务拆分，例如该案例就是使用哪个业务的营业额大就算是重要业务，例如营业额前三的业务是账号、道具、游戏币，那么就优先将这三个服务进行拆分。
当时拆分的方法是先拆服务，后拆数据。实际上这并不是最佳实践，例如在当下，微服务的案例已经非常成熟，先拆分服务再拆分数据可能会导致二次拆分，虽然每一次拆分会比较简单，但是两次合起来反而会更复杂。
（2）微服务第2式-按业务稳定性拆分
例如商家服务和客服服务已经非常稳定，可以优先考虑将这两个服务拆分出去，其他还在快速叠的功能不要影响已经非常稳定的功能。
（3）微服务第3式-按业务领域拆分
最终所有的功能都按照业务领域进行拆分。
5、手游交易中台
由于手游交易有很多入口，例如自由的Web、小程序、App，集团有的淘宝、咸鱼，那么如果对接这么多的入口呢，当时想的方案就是采用手游交易中台来解决。
手游交易平台具体如何落地，当时设计了三种落地方案：
（1）手游交易中台设计思路1-理想型
将各个微服务名称改一下，例如服务层将客服微服务改名为客服中心，项目层将手游交易平台改为手游交易平台，这种方案也是很多公司在做中体时的落地方案。
（2）手游交易中台设计思路2-嵌入式：
由于集团本身有电商中台，其本身就支持Web、小程序、App、淘宝、咸鱼等多个入口，那么将手游交易直接嵌入到集团的电商中台即可。
这种方案在落地时有很大的问题：
业务差异大、数据模型不通，例如：电商中台的商品分类是一级类目、二级类目、三级类目，而游戏商品分类：类目-游戏-平台-账号-区服。
业务相似度不高：手游交易是虚拟发货，实物电商是物流发货，业务相似度不高，如何兼容？
（3）手游交易中台设计思路3-打通型：
手游交易中台和电商中台将数据打通。
这种方案在落地时也有很大的问题：
业务差异太大，数据模型不通，怎么改造？游戏商品分类：类目-游戏-平台-账号-区服。
手游交易是虚拟发货，实物电商是物流发货，如何兼容？
两个平台如何保证数据一致性？例如：一件商品两边都卖会超卖，只放一边卖会导致成交机会下降。
（4）中台思路对比
下图是三种中台落地方案的对比，首先从影响范围上说，理想型需要咸鱼、淘宝接入手游交易中台，而嵌入式的需要手游交易融入电商中台，打通式电商中台和手游交易平台都需要改造；从业务生态来说，理想型能够适用各种生态，嵌入式就是能适用阿里的生态，打通式也可以适用所有生态；从改造成本来说，理想型方案中，咸鱼和淘宝的改造太大，嵌入式方案中，手游交易平台改造成本很大，而打通式方案中两边都要改造，总成本也很大。
总和上述决策方案，最终选择的落地方案为打通式。
6、其他中台设计思路
以某轻奢品牌设计思路为例，其采用的是隔离型策略，总体方案是电商中台和自营中台两套生态，各自运营。具体的落地方案如下：
同样的商品，通过人工库存拆分，分配到不同的生态。每个生态都有对应的运营人员，数据不打通，各自显示各自的销量和评价。
那么就有一个问题，为什么轻奢品牌可以这么做，而手游交易不能这么做？这是因为该案例和手游交易从业务上还是有本质的区别的，例如在本案例中，有一千个名牌包，其中400个在自营平台售卖，另外600个在电商中台售卖，或者数量交换一下也行，只要数量相差不大，用户在哪个平台看到的评价都差不多，至于销量没有汇总则影响不是很大，而对于手游交易平台来说，账号或者装备都只有一个，在一个平台交易后就不能在另外的平台交易，那么数据同步就是设计的关键，因此不能采用这种隔离型策略。