第二个原因就是上面说过的，单体应用群通过ESB暴露出去，虽可以实现信息拉通，但是无法达到中台快速迭代的目标。
2.4、误区四：觉得中台太复杂
很多传统企业一听中台，就觉得一下子要上N各系统，将原来的服务拆分的七零八落的，然后看看自己手里就这几十号人，应该搞不定，于是望而却步，任务中台太复杂，这是互联网公司的事情，传统企业不应该参与。
其实这是误解，中台的构建有两种方式，封装式和重构式，传统企业往往害怕的是重构式，然而其实中台的建设有渐进的过程，可以保留原来的系统，通过逐渐的封装，构建自己的中台。
2.5、误区五：觉得中台太技术
有的企业比较有钱，觉得中台的构建就是个技术问题，只要花钱买一个一线互联网公司的大平台就搞定了中台，这也是一个很大的误区，因为你没有自己的架构师团队和中台团队，没有自己的流程和规范，没有自己沉淀可复用能力的方法论，还是没办法应对业务的快速迭代。这就像你在健身房看到一个健身教练用一个很牛的器械练了六块腹肌，你就把器械买来，自己不练，那也没有腰部力量呀。
3、中台建设的两种方式
3.1、封装式
传统企业由于采购大量传统服务，可采用封装式构建中台。
前台APP或者门户一旦需求改变，后台采购系统或核心稳态系统不可能随之改变，所以中间封装中台服务层
传统服务多使用SOAP协议暴露接口，可通过ESB或者API网关转换为RESTFul接口对上暴露
服务层采用最新微服务架构进行开发，适应前台快速迭代
3.2、重构式
互联网公司历史包袱轻，大型银行，运营商等由于技术力量充足，可对于部分系统进行全方位的重构为微服务架构，并以此为底座构建中台
可全面实现自主可控，和快速迭代
4、中台如何解决第一阶段的问题
接下来，我们来看中台如何解决第一阶段的问题，我们还是从企业架构的五个方面逐个分析。
4.1、业务架构：架构服务化，侧重变化多和复用性，领域拆分与解耦
上一节，我们讲了影响快速迭代的问题是架构腐化问题，那如何解决这个问题呢？就是通过服务化的方式，将不同的业务领域拆分到不同的工程里面去。
这样第一会增加可理解性，工程更加的简洁，每个工程只做一个领域的事情，职责单一，这样就会既容易修改，也容易Review。其实按照人性角度来讲，易Review更加重要，因为拆分后的服务虽然聚焦于某个领域，也会腐化，易Review能够早日发现腐化，早日修复。
第二会增加可测试性，越是耦合在一起的庞大代码，测试覆盖率越低，越容易出现问题，而拆分后的服务测试更加容易展开，覆盖率变高。测试覆盖率是验证架构有没有腐化的指标，也是领导或者架构委员会能够看到的，也有利于及时制止和修复腐化。
第三，也即最重要的就是可观测性，服务化之后，一般要有服务统一的注册发现和接口管理平台，通过这个平台，服务之间的调用关系以及接口的设计和文档，领导和架构委员会都能看到。
调用关系变乱是架构腐化的重要指标，服务之间的调用应该分层单向调用，严禁循环调用的，如果多个服务之间的调用一团乱麻，那就说明腐化了，应该及时制止和修复。另外接口不符合规范，也是架构腐化的重要指标，接口如果开始出现模糊，或者传入大量的参数，甚至传入Hashmap将参数通过key-value的方式传递，那就说明里面的架构已经腐化了，应及时制止和修复。
这样就是实现了架构始终保持在轻债务的阶段，这样开发敢改，同事容易Review，QA容易测试，领导和架构委员会也看得到的效果。
而且服务化拆分后，会将很多内部的功能，暴露成接口对外提供服务，并且接口经过Review和设计，而且文档和调用方式都在注册中心上，非常方便其他服务调用，从而实现可复用性。
从而最终实现了快速迭代。
你可能会问，你说了半天服务化，和前面的中台啥关系呢？中台这个词其实是给业务方听的，具体到技术手段，就是服务化。作为技术部门，需求都是从业务方来的，业务方其实不关心我们拆了多少服务，就是希望能够快速完成需求，而服务化就是为了完成这个目标的，只不过你说服务化，甚至拆分啊，架构啊，业务领导听不懂，所以就说为了更快响应他们的需求，给他们建设了中台。
那服务化应该从哪里开始呢？
这里很多技术人员都会犯的错误是，从数据库出发，看数据库结构如何设计的，按照数据库最容易拆分的方式进行拆分。这样是不对的，没有站在业务的角度去考虑问题。应该借鉴领域驱动设计的思路，从业务流程的梳理和业务领域的划分出发，来划分不同的服务，虽然最后映射到数据库可能会拆分的比较难受，但是方向是对的，只有这样才能适应未来业务的快速变化，起到中台应该起到的作用。我个人认为，方向比手段要重要，方向对，当前痛一点没什么，但是当前不痛，方向错了，还是解决不了问题。
