简述
因为我们项目组正在做一个类似于公司主体数据的处理平台。它是为了解决其他项目组都需要对公司主体业务产生的数据进行处理的问题。我原本觉得这个项目挺好的，可以解决一些重复的造轮子。但是在与一些同事的交流中，说我们这个项目有点阿里的中台战略的意思。但是还是在重复的造轮子。所以我就对这个中台战略有些兴趣。就去看了《企业IT架构转型之道：阿里巴巴中台战略思想与架构实战》。这本书不仅让我对中台战略有了一定的了解。也让我对软件架构的发展过程以及各个架构的优劣势和更替原因有了更深的理解。同时在书的后半部分也讲述了阿里内部的分布式服务框架：HSF。
IT架构更替
IT的架构是随着应用的不断扩大而进行改变的。最开始，我们的应用是类似于烟囱的结构，每个应用都是一个独立的系统。各个系统之间没有什么联系，或者通过一些接口来连接。这种结构会不可避免的重复造轮子。并且各个系统之间的通信会两两连接，导致系统之间的关系比较混乱。所以在发现了这些问题之后。出现了有个SOA架构的理念。它主要是面向服务的，服务之间松散耦合，并且服务注册和自动发现。在基于这个理念下，一些传统软件厂商提出了以ESB（企业服务总线）的方式来实现SOA的方案为主流。它很好的解决了服务之间重用的问题，可以避免重复造轮子。它是一种中心化的服务框架。所有的服务通过企业总线连接。这个也是现在大多数在公司正在使用的方式。但是，它还是有着它的局限性。因为他是基于企业总线的，它对于扩展不是很支持，而且容易引发雪崩。然后，互联网架构和技术的普及，大家就想有一种去中心化的服务框架。因为互联网公司更看重扩展的能力，所以阿里就基于SOA以及去中心化的思想。提出了中台的架构，来实现他们阿里巴巴内部系统的重构。这个中台战略就是把公司中改动不是很频繁的，核心的服务集中在中台上，让他们为其他的前后端提供服务。看到这里，可以大家都会有疑问，这个去中心化的策略会不会导致烟囱式的出现的问题，即服务之间相互通信，一种点对点的方式。但是其实，这种框架一般是运行在企业内部网络上（不会出现内外网的服务交互），并且基于统一的连接标准，可以让服务的交互效率最高。
两种SOA架构的对比
传统的服务总线的SOA架构，它是把服务通过一个企业总线连接，各个服务之间通过服务总线的相互通信，这相比中台的架构，服务之间的通信时间大了一倍。同时，一般来说，服务总线需要提供的功能也比较多，如服务发现，注册，路由等，当规模变大后，扩展消耗的资源就很多。而且在互联网中，企业总线一般是集群部署，但是由于服务请求的峰值不可测的情况下，容易使得连接一个企业总线的服务请求量过大，导致企业总线出现故障，这个时候，服务器的压力就会分摊到其他的总线上，导致其他的总线一起崩溃。造成雪崩式的情况。而且在发生这种情况下，故障恢复就会变得很难，因为这个时候服务器的重启是没有用的，它启动后，立马就会被压垮。只能是把前端的请求关闭。然后重新启动，但是这样，故障的原因就变得很难查了。
中台战略实践的问题
1.中台定位问题
阿里在实践中台战略的时候，是把淘宝，天猫中的用户，订单，店铺等核心的服务集中起来，放在一个叫共享服务事业群。本意上，这个事业群应该与天猫淘宝是同一级别的，但是在实际上，共享事业群更多是support的角色。作为天猫淘宝的技术支持。这个问题更多的是大多数it部门的问题，他们的定位就是为公司的业务提供技术支持，而不是一个独立的部门，在书中，作者解释的是因为技术人员无法基于业务提出能够让公司盈利的策略。
2.中台滋养问题
第二个是共享业务没有服务的滋养，因为共享业务刚开始还是会比较单薄的，但是我们不能因为他不能提供新的功能，就放弃他，然后重新造轮子。这样的话中台是不可能真正建立起来的。这个也就是我开头和同事在讨论的时候说的，我们原来的系统里是有对公司业务的数据的处理的，但是只是跟不上现在的业务发展了，所以就有了我们新的项目。作者说，服务是最不需要稳定的，稳定的就意味着容易跟不上业务的步伐。老实说，这个对于我来说是一个观念上的转变，不过也是抓住了我们程序员的心理，宁愿重新建项目，也不想维护旧的项目。