阿里IT架构转型的实践

这本《企业IT架构转型之道》,副标题是“阿里巴巴中台战略思想与架构实战”。作者钟华,是阿里中间件团队的核心成员,首席架构师。
本书主要讲了三个问题。
为什么要实施中台战略?
2015年底,阿里巴巴集团对外宣布全面启动阿里巴巴集团2018中台战略,构建符合DT时代的更具创新性、灵活性的“大中台,小前台”组织机制和业务机制。
为了实施这个战略,阿里共享业务事业部诞生,并主导了这一波阿里IT架构的演变。
阿里实施中台战略,其中的一个重要契机是阿里的管理层在2015年参观了一家叫SuperCell的公司,没错就是开发了《部落冲突》,然后2016年被腾讯以86亿美元收购了80%以上股份的不到200人的公司。为什么他们可以开发出风靡全球的游戏,是因为他们积累了非常科学的研发方法和体系,能够不断尝试,快速的从失败中学习。这种能力给了阿里很大的震撼,学习回来后半年,阿里的中台战略应运而生。
而作者从IT架构演变的角度来诠释了为什么要实施中台战略。
- 原来的烟囱式建设会带来重复开发;
- 烟囱式系统之间的集成和协作成本高;
- 烟囱式系统不利于业务沉淀和数据的协作,这在DT时代尤为重要;
- 从业务角度,中台是为了给前台赋能,更灵活的响应业务。
我从中还解读出这么几个信息,一是,IT架构的转型一定是为了配合组织机制和业务机制的发展,这也符合康威定理;二是,IT架构转型一定是举全公司之力,并不是IT部门一家能搞定的;三是,中台战略,是解决大企业有效的进行协作创新的有效手段。
“中台”其实并不是阿里发明的,在IT领域具备中台属性的架构早已诞生。从最开始的企业服务总线(ESB)到PASS(平台即服务)到SOA服务框架,到微服务,无一不具备支撑中台战略思想的潜质。
阿里如何实现IT架构转型,以支撑中台战略?
最终阿里选择的是分布式的SOA服务架构,来建设中台的服务中心。跟大部分传统企业一样,也涉及到去IOE的问题。IOE的架构,作为OLTP(在线事务处理)领域,其实非常成熟,但是为了利于扩展,实现系统的渐进式建设,必须要打破IOE的架构,同时还要保留原来的数据以及事务的一致性。这里涉及到几个重要的问题。
为什么是分布式服务架构?
阿里的业务规模和复杂度决定了只能采取分布式的服务架构。如果你的企业规模不大,业务数据不是特别服务,采用集中式的ESB也无所谓。
服务怎么拆?
这跟企业大了,必须划分部门是一个道理。有四条原则:
- 高内聚,低耦合
- 数据完整性
- 业务可运营性
- 建设渐进性
总之,就是责任划分的比较清楚,每个中心(部门)规模相当。面向中台的服务中心,就是要把共享服务划分好,比如客户中心,订单中心等等。但,同时又不能拆分的过细,比如会员数据如果跟客户中心高度相关,按照数据完整性的原则,就不应单独拆分出来。
数据怎么拆?
数据库就像图书管理员,但你的藏书规模不大的时候,一个管理员就能应付过来了;但是如果你管理的书籍和资料非常大的时候,管理员就成了瓶颈,这个时候,就需要增加人手。
当有多名管理员的时候,你可能会让张三负责小说,李四负责社科,王五负责自然科学。这是基于业务划分的原则。
但是,马上发现张三忙的要死,李四闲的要死,为了避免这种情况,就需要采用随机的方法划分数据。
过了一段时间又发现有一些热门的书籍,比如小说,借阅的人非常多,因此你会多买几套,找专人管理起来,提高效率。对数据而言,小说就相当于热数据,因此就复制一份放到内存里面,以提高访问效率。
业务怎么拆?
在IOE时代,写应用的一项重要工作是保障事务的一致性,这需要数据库加锁来保障。在服务中心化之后,一次交易就涉及跨中心了,如果还靠数据库来保障事务一致性,明显不现实。所以,就需要用很多软件的办法来解决事务一致性的问题。
一是把大事务拆小,分阶段异步完成。在这种思路下需要在业务层面来协调分阶段提交的关系。有的事务部涉及主流程,比如下发通知信息等,就直接剥离;有些小事务可以用反向的业务来考虑,而不是事务回滚,比如退货以后,进行退款,而不是取消之前的交易。同时要可以增加交易校验机制和增加资源预占以及两阶段提交。
二是引入柔性事务的概念,即交易最终的状态保持一致,在这个过程中,容忍一定程度上的不一致,换来高可用性。比如数据库锁比较豪资源,那么采取软件方式实现无锁,可以有效提升资源效率,但需要牺牲一定的交易过程中的用户体验。同时还可引入日志和补偿机制,从更底层来保障事务一致(对业务逻辑依赖没那么强)。
另外有些分布式系统的新问题,需要考虑的,比如机器和机器之间的通信,消息可能会丢(单机不存在这种情况),所以要考虑采用可靠消息传递机制,远程模块之间一定要用异步消息来驱动。
中台的定位发生了哪些变化?
从阿里给业务中台的绩效考核,就可以看出中台在这一波变革中承担的角色:
- 服务稳定是前提-40%
- 业务创新-25%
- 服务接入量-20%
- 前端满意度-15%
更复杂的架构必然带来运维的问题,阿里开发了基于海量日志可视化分析的鹰眼系统,可以对服务以及服务调用链进行全方位的监测,同时日志中反映出来的业务数据可以跨业务领域跟踪故障,实现业务级的监控。
监测出故障或隐患后,就要围绕平台的稳定性开展业务限流、流量调度、服务降级、全链路压测等工作。
考核业务创新,说明了中台需要跟前台紧密合作,要通过业务滋养服务,实现业务的持续沉淀,抽象后可以扩大应用的场景。
服务的接入量以及前台的满意度,基本体现了中台的量化价值,服务调用的次数越多,前端越满意,反映了内部市场部的机制,完全可以通过内部结算来体现中台的价值。
从阿里的实践来看,中台让传统的IT从单纯的技术,向业务迈进一大步,唯有不断通过业务滋养系统,IT架构才能持续演进;而前台也更贴近技术,能够借助中台能力快速响应市场,而把精力可以放在不断提升客户体验上。而最终的结果,也证明了这一点,阿里的中台和前台实现了定期轮岗,这在传统的企业是很难想象的。
写得很好,这里有这本书的电子版可以下载,感兴趣的可以下载看看。https://pan.baidu.co m/s/1YKdfj2QByhbO0vN l8sVUTg