最近阅读了《企业IT架构转型之道》，感触较大，和我们公司这几年遇到的问题有很多相似之处，如果能够早几年看到这本书，一定能少走很多弯路，下面说说我对共享服务体系的感受。
先介绍一下这本书，我认为阅读一本书，最重要的是弄明白作者的逻辑，作者怎么讲的，为什么这么讲，了解这个了就有全局观了，就像看明白地图后再出发一样。作者的目的就是要讲清楚共享服务体系，是什么，如何建设，是经过阿里巴巴中台战略转型而产生的并且成熟的，是经过实践的可靠体系：
再说说企业IT架构模式经历的几个阶段，不代表全部，不过典型的3个阶段，跟我们公司的经历非常吻合，相信不少人也经历过这个过程。
一、烟筒式
各项目独自为战，以项目或团队模式开展工作，基本都是从0开始开发，好点的能做到代码复用，组件复用等，不好的几乎不停的重复造轮子。最大的弊端就是：
1、重复建设，重复建设并不可怕，可怕的是不停的重复建设，我们公司前几年有平台组专门做一些通用组件，供各项目使用，由于种种（能力，设计，制度，资源等）原因，组件难以满足各个项目，使用者都觉得组件不好用而自己开发，最终重复建设浪费不少资源。
2、系统交互的开发、协作成本高，这个估计是最耗费心力的事，两个团队做接口，从接口的设计，开发，联调，到上线后问题的排查，每一个环节都会经历很多扯皮，甚至撕逼的事，尤其几个系统之间，越是紧密耦合越高，协作成本越大。资源都紧缺的情况下，求谁都不行，找领导协调结果就是谁声音大谁资源多，结果可想而知。
3、缺少业务积累和沉淀，难以持续发展，大家都在重复造轮子，只造了适合自己的轮子，缺少对轮子真正了解的人。
4、系统发展问题，随着业务越来越多，系统越来越大，越来越复杂，问题也越来越多，一个小问题就可能导致系统全部宕机，也没人对整个系统了解，只了解自己做的一点点……想想我们最多时候100多人在一个产品上开发，经常发版前最后一天都还有一百多bug，不到后半夜是发不了的，能够发布还是因为太晚了大家都妥协了。
二、服务化模式
解决系统大且复杂的方案，就是拆分，不论水平拆分还是垂直拆分，不论按业务拆分还是按功能拆分，影响都不是很大，最核心最关键的就是要拆分，拆分后也就能够复用了，起码能够达到功能复用了，好一些的能都达到业务复用，而且小功能出问题影响范围只是自己的服务内部，的确是非常有效的方案。
但服务拆分随之而来的问题也不少，服务拆分过多需要服务治理，实施部署麻烦需要自动化运维，服务之间依赖复杂，数据处理复杂需要ESB等，如果企业就一个大型项目还好，如果是多个项目，还是按照项目或团队方式交付，服务化只能沦为一种技术架构方法来使用，依然难以发回作用，还是解决不了。
三、共享服务体系
这个模式从技术架构上来说和微服务本质上差别不大，但关键的是要从组织结构，研发模式上来调整。
理念就是“厚平台，薄应用”，所有产品都在业务共享服务体系（中台）上进行研发，重复的轮子放到业务共享里面，相当于站在巨人的肩膀上进行研发。
关键点是图中的各个XX中心，相当于现在提的较多的微服务，这些XX中心（微服务）不是分散在各个团队，而是集中于一个大团队，业务共享服务团队，有独立的团队来做，也更利于业务的沉淀。
相比前面的好处在于
1、降低研发成本，提高研发效率。打破了产品壁垒，之前是系统之间要数据，现在是都去找共享服务中心要数据，共享服务中心提供统一的，标准的数据。减少了系统间交互、团队间协作的成本。
2、站在巨人的肩膀上。新产品研发不用考虑之前已有的东西，可以快速孵化新的产品，试错成本低，产品敢于创新，敢于拥抱变化，原来追竞争对手都很困难，现在相当于竞争对手的产品经理不停的给我们提供新点子。
3、可持续发展，技术和业务能力能够沉淀积累。这些XX中心的业务，为了适应不同情况，需要了解更多更深入的场景，更利于业务架构师的产生。
能够达到的研发效率提高如下：
最后，说起来容易做起来难，共享服务体系的建设还需要考虑非常多的内容，更需要非常多的配套工具，阿里巴巴有很强的技术团队，自己研发改进了很多工作，这个不是一般小公司能玩得起的，不过一般小公司也没这么大的信息化规模，倒也不需要这么重的架构。具体建设时还要考虑的方面：
1、服务框架的选择：能够分布式计算，去中心化，服务自动注册与发现等。
2、共享服务中心的建设原则：业务划分原则，如高内聚低耦合，如何保持数据完整性，如何做到业务可运营，如何做到渐进性建设等。
3、数据拆分原则：数据库分库分表等原则，如何支持水平扩展等。
4、异步化与缓存原则：业务流程要异步化，如何异步化，异步化下事务如何处理等。
5、数字化运营能力和平台稳定性能力，这两个也是共享服务体系中必不可少的能力，如何建设这两个能力。
6、还有最重要的团队建设模式，考核方式，团队间协作模式等等。
这些就没办法给出一个标准答案，甚至都没办法给出一个有效的答案，只能多去找找其他人怎么做的作为参考，总结一些原则或规律，结合自己的实际情况进行改进。希望这篇文章能够给你带来启发，引起你的思考，设计出更加有效的架构或研发模式。
