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