明眸善睐系列--企业IT架构转型之道：阿里巴巴中台战略思想与架构实战

2019独角兽企业重金招聘Python工程师标准>>>

一、阿里巴巴中台战略的思考

关于程序员与业务关系的思考

• 技术人员不懂业务，这个不懂不是不懂业务流程，而是没有对业务的深刻理解，从而提出创新，为企业带来新的业务增长点
• 不懂业务的原因是因为IT部门是项目制的系统建设模式，能力强的员工顶多也就是负责多个项目；并没有某一专业领域的知识和经验沉淀。
• 对着时间的流逝，IT部门失去了最初的工作积极性和业务创造性；
• 知其然不知其所以然，谈不上称为业务领域专家，更谈不上对业务的创新和独到见解；

SOA最初的核心理念

• 松耦合的服务带来业务的复用，通过服务的编排助力业务的快速响应和创新
• 核心价值：服务重用

关于部门之间组织的思考

• 原先是UED、架构、开发、运维、DBA组成的团队，缺点是：技能提升慢、容易疲劳
• 现在有了中台，出现业务架构师，可以在业务中浸染，即懂技术又懂业务，可以完成创新。
• 信息中心部门从之前的“业务支持”的组织职能，转变为基于企业核心业务和数据进行运营的部门
• 接下来社会进入开放共享的时代，这个部门将会成为公司的宝贵资产

二、分布式服务框架的选择

背景

一个大项目带来的困境：几百人维护一个war，导致问题：

• 协作成本超高
• 应用复杂度超高
• 错误难于隔离
• 数据库连接难扩展
• 应用扩展成本高

方案

需要进行横向和纵向切分，先横向分层，再纵向分业务线、分服务，最后变成几百个war，分别独立部署
阿里巴巴选的是HSF：

HSF采用Netty+Hession来实现服务交互。hession序列化性能可能不是最好，但在复杂场景下的处理能力、稳定性会更好。

SOA核心特征

1. 面向服务的分布式计算
2. 服务间的松耦合
3. 支持服务的组装
4. 服务注册与自动发现
5. 以服务契约方式定义服务交互方式

微服务的典型特征

1. 分布式服务组成的系统
2. 按照业务而不是技术来划分组织
3. 做有生命的产品而不是项目
4. 智能化服务端点与傻瓜式服务编排
5. 自动化运维
6. 系统容错
7. 服务快速演化

Docker

Docker的出现让微服务概念再次大行其道，Docker不能解决的微服务问题有：

1. 如何有效的服务管控，如链路跟踪、链路分析、实时业务指标监控
2. 分布式事务难题
3. 自动化运维与平台稳定性
4. 微服务的服务设计
5. 原有的组织架构是否满足微服务架构持续发展

三、共享服务中心

演变

越来越多的服务能力会被沉淀到共享服务中心。先建立了用户中心；后是商品中心，提供的服务能力有：商品描述能力、商品发布能力、商品管理能力、商品巡检能力、商品数据分析、商品评价；然后是交易中心和店铺中心。

服务中心

概念如下：

1. 一定是不断发展的，不做超前设计或理想化架构
2. 服务形式多样化，不一定非是接口，也可以是界面形式的服务能力
3. 服务中心可以进一步划分，真实的服务中心场景中，两种形态都是正常的：单个服务模块和多个服务模块（例如交易中心有订单服务和购物车服务）

目的如下：

1. 通过共享提供可重用性
2. 通过服务化达到敏捷性
3. 通过统一的数据架构来消除数据交互的屏障

服务中心的建设一定要兼顾三个方面的需求：设计、运营、工程。也就是设计好、架构可实现、有一定运营能力。
基本原则如下：

1. 高内聚、低耦合。在一个服务中心内的业务依赖很高，而不同服务中心的业务隔离应该较大。有些业务不需要拆分太细，比如会员中心中的积分系统，等到他足够丰富的时候再拆分也不迟
2. 数据完整性。要有大数据思维，不光是关键数据，还要考虑相关性数据。不光是在线数据，还要考虑离线数据
3. 业务可运营性原则。服务中心首先从业务出发的，用大数据能力提升运营水平是服务中心原则之一
4. 渐近性的建设原则。推荐小步快跑的方式逐步推进

四、数据库问题

不同的服务中心采用垂直分区的方式，单个服务中心数据达到极限呢？例如用户中心有6亿数据，放在单表中是不可能的事儿。这时需要水平分区，根据id进行hash取模分到不同的100个数据库中。但如果出现跨表join、事务操作，数据统计、排序的情况，则对数据库运维管控提出了更高要求。08年，阿里内部已经开始了分布式数据库的研发工作。
08年，研发了分布式数据层框架TDDL（Taobao Distributed Data Layer），针对分库分表场景，提供了对各种业务场景的支持。平均每天SQL调用超千亿次。现在已变成阿里云服务：https://www.aliyun.com/product/drds，开源：https://github.com/alibaba/tb_tddl 随着表的复杂，TDDL也不能完全解决问题，这时候出来一个数据异构索引平台：精卫

五、柔性事务

数据库事务核心体现在ACID：原子性、一致性、隔离性、持久性
在分布式领域，有人根据CAP和BASE，提出了柔性事务的概念

CAP理论：一个分布式系统最多只能同时满足一致性（作为一个整体是一致的，不会出现不同的副本读取数据不同的情况）、可用性（访问数据可以得到及时的响应）和分区容错性（分布系统遇到某节点或网络分区故障时，仍然能够对外提供满足一致性和可用性的服务）三项中的两项

BASE理论：核心是即使无法做到强一致性，也要做到最终一致性。指的是基本可用（分布式系统出现故障时，允许损失部分可用性，保证核心可用。例如流量激增，服务层只提供降级服务）、柔性状态（允许系统存在中间状态，而该中间状态不会影响系统整体可用性。允许副本同步的延时就是柔性状态的体现）、最终一致性（所有数据副本经过一定时间后，最终达到一致的状态）

高可用

互联网的核心是：高可用。互联网首先要考虑的就是高可用。系统的不可用就意味着商业损失，例如淘宝业务高峰的10秒或双十一。如果系统不可用，还会造成对平台的伤害。
高可用=系统构建在多机=分布式系统；高性能=分布式系统的副产品
分布式系统与单机系统的最大区别是：单机系统不会丢消息，而网络会。类似Paxos协议，需要一半以上多数系统确认后，才认为是成功，分布式的首选不是这种强同步而是最终一致。

分布式事务

传统分布式事务，是两阶段提交协议，著名的有X/Open组织的标准。
显然，在提交事务的过程中需要在多个资源节点之间进行协调，而各节点对锁资源的释放必须等到事务最终提交时。那么跨多机的锁耗费的世界就是毫秒级，如果有1000台机器，就要完蛋。

柔性事务

柔性事务引入了：

• 日志和补偿机制：柔性事务的原子性由日志保证。事务日志记录事务的开始、结束状态、参与者节点信息。为避免单点，数据REDO/UNDO日志一般都记录在分布式节点上--业务数据库。通常柔性事务能通过日志记录找回事务的当前执行状态，并根据状态决定是重试异常，还是回滚前序步骤
• 可靠消息传递：由于“网络通信危险期”的存在，节点间的消息传递会有“成功”、“失败”、“不知道成功还是失败”三种状态，这也给进行分布式事务处理时提出了更多的考虑和要求
• 实现无锁：造成数据库性能和吞吐率瓶颈的往往是强事务带来的资源锁，但放弃锁也就意味着放弃隔离性，会造成大量的数据脏读、幻读等问题。实现事务隔离的方法有很多：1、避免事务进入回滚；2、辅助业务变化明细表；3、乐观锁）

阿里巴巴内部柔性事务的几种实现：

1. 消息分布式事务
2. 支付宝XTS框架（Try/Confirm/Cancel，典型的补偿性事务）
3. 阿里巴巴AliWare TXC事务服务（最终一致性、自动回滚和补偿、易用）

六、服务监控与调用链追踪

服务调用错综复杂，出了问题很难定位或无人承认。这就需要鹰眼系统了，主要包括了

• 服务实时监控
• 服务调用链追踪
• 服务调用链分析
• 业务全系排查
• 业务实时监控

简单说明图：

七、平台稳定性

要不断接入新业务、每天几千亿的服务调用中保持稳定、双11中如何确保平台稳定如山、机房断电时如何保障稳定运行？
稳定性体系非常广泛，比如机房的布线、网络通信、硬件部署、应用架构、数据容灾等。
从应用架构设计来看，主要包括

• 限流和降级：限流是保险丝，1000W进来先处理100W，另外的排队。通过在Nginx上实现的扩展组件TMD--nginx-http-sysguard实现了域名类限流、cookie限流、黑名单等；Sentinel平台，对资源调用的控制平台，涵盖了授权、限流、降级、调用统计监控四大功能模块，会把规则发到Diamond配置中心；服务降级就是把非核心服务先关停
• 流量调度：实际环境中，所有机器的实时服务能力是有差异的，可能因为网络抖动、CPU超配、某个应用启动时负载飙高、资源竞争、JVM假死、JVM垃圾回收。单机的问题在链路上会被放大，面对这种影响，阿里巴巴实现了流量调度平台，用于屏蔽所有机器的软硬件差异，根据机器的实时服务能力来分配机器的实时流量
• 业务开关：Switch是一个轻量级的开关集成框架，用来集中管理集团各应用的开关
• 容量压测和评估：摸索出一套面向分布式应用架构下应用系统容量压测和评估的自动化平台；线上流量自动切换到压测环境，可以评估出大促时需要的资源
• 全链路压测平台：主要对零点峰值流量进行评估，对网站承压能力进行测试
• 业务一致性平台：比如优惠券使用了却无效的不一致。实时业务审计平台应运而生，解决了业务一致性的问题

转载于:https://my.oschina.net/lizaizhong/blog/1611141