阿里技术嘉年华 - aDev 内容感悟

阿里技术嘉年华-aDev内容感悟 占进冬 2013年7月

写在前面

这次杭州之行，干货确实有，但很多时候自己没有切身体会或者没有相同规这次杭州之行，干货确实有，但很多时候自己没有切身体会或者没有相同规模的应用场景可能很难产生共鸣。对于我个人来说启发的价值大于实际应用的价值，有些抽象的东西不管大系统还是小系统都是很有指导意义的。这个分享内容主要是自己在这次会议中感悟到的一些东西并结合了大牛们的一些经验之谈，有不对的地方，欢迎批证。

什么是aDev

业务架构&后端技术 “aDev由淘宝技术工程师自由发起的组织，主要关注的后端技术。关注开发人员和架构师在完成不同系统中的问题解决和经验实战，以及相关的技术趋势。整个软件架构中，从不同的角度可以看到很多视图，aDev主要关注的是业务架构和技术架构，之所以说是后端技术，是因为在整个软件架构中，技术架构在底层为上层业务架构所服务。

逻辑架构、 物理架构、部署架构 ……

宏观上：整个淘宝的架构是业务 拆分，后端技术共享。微观上：具体到某个子业务上，依然能得到业务拆分和技术架构作为底层服务的类似的结构。抽象：某个技术架构依然可以看成底层模块为上层模块服务的结构。淘宝业务和后端技术再抽象……什么是架构？

架构=组件+交互+约束 架构=结构+结构+…… 结构=组件+交互+约束

什么是业务逻辑

对于业务逻辑的理解很多人仅限于对三层架构中业务逻辑层的理解对于业务逻辑的理解很多人仅限于对三层架构中业务逻辑层的理解 => 仅仅是对数据访问层的简单封装。原因是我们大多接触的三层架构都很简单，基本上都是对数据库的CURD操作，比如OSSP的运营管理系统业务逻辑= 三层架构中的业务逻辑层

分层的目的：为了分离和复用。 领域逻辑：业务逻辑也叫领域逻辑，每个人站的领域不同，看到的业务逻辑的范围自然不相同。这既跟软件客体有关系，也和架构师主体有关系，因此同样一个软件不同的人分层也不同。对于甲来说，从软件1和软件2 中抽取公共部分之后，剩下的就是各个软件中的业务逻辑了。而对于乙来说，从软件1和软件2中没有抽象出任何公共部分，那么设计出来的软件架构可想而知：必然将业务逻辑穿插于软件的各层。

个人理解： 以某个领域的视角，将一个软件中所有可以复用的部分抽象出来，那么剩下的就是业务逻辑。大部分都能做到将数据访问和界面展示抽出来，所以有了三层架构。具体例子：比如VAServer和VAClientServer将请求信源也独立成一个Source.jar包可以复用，那么对于VAServer和VAClientServer来说剩下的BLL就是各自业务逻辑了。如果站的更高一点来看OSSP接口和灵犀业务服务器，那么Source.jar其实也是属于业务逻辑了。但是OSSP接口和灵犀业务服务器的数据访问层理论上依然是可以抽象出来的，再比如配置也是可以抽出来的。

检验： 一个检验程序是否将业务逻辑分离出来的方法很简单：让别人复用你抽象出来的组件。

分布式的阿喀琉斯之踵

阿里分布式数据库服务

DRDS是阿里巴巴即将对外发布的云服务，阿里目前已经提供关系数据库服务RDS（http://www.aliyun.com/product/rds/）DRDS是阿里巴巴即将对外发布的云服务，阿里目前已经提供关系数据库服务RDS（http://www.aliyun.com/product/rds/）本质：DRDS的后端不是真正意义上的分布式数据库，而是关系型数据的分布式处理，它是介于应用程序与关系型数据库之间的中间件。好处：通过阿里分布式数据库服务，可以将一张表中的数据映射到不同的物理数据库服务器上，从而给数据库带来弹性扩展能力。从大处讲，使用了阿里分布式数据库服务你就拥有了一个海量数据库，不用担心数据库物理服务器的计算能力跟不上；从小处讲，在开发中你不用再纠结于如何进行表拆分。同时可以在线数据迁移（全量复制+增量复制）

限制： • 分布式事务：单机→多机，网络延迟不可避免 • 分布式锁 • 分布式join：基于内存→ 基于网络 • 分布式索引：保证一致性、实时更新索引 • 分布式分页 • ……

这些限制很多都是相互依赖的，本质上都是一个问题。我们没法同时获取分布式系统中所有节点的状态信息，这其中的罪魁祸首就是网络延迟，节点之间距离越远，延迟也就越大。这些限制很多都是相互依赖的，本质上都是一个问题。我们没法同时获取分布式系统中所有节点的状态信息，这其中的罪魁祸首就是网络延迟，节点之间距离越远，延迟也就越大。分布式的一个原则：“不要分布式”，两层意思： 1）当我们的规模单机就可以搞定的时候完全没必要拆分； 2）当不得以需要拆分后，尽可能利用单机的资源： ①尽可能走内存； ②一次性查询需要的数据要放到一台机器上（如：文章和文章的评论列表） ③合理的冗余：减少网络开销

一些理论和思路： 分布式事务： 1）两阶段提交协议：阻塞的因为为了克服不可避免的网络开销保证在获取到所有节点的状态后再做出决策，这种方式存在着很大的代价： A组织B、C和D三个人去爬长城：如果所有人都同意去爬长城，那么活动将举行；如果有一人不同意去爬长城，那么活动将取消。 A就是协调者（coordinator），B、C、D就是事务参与者（participants、workers）→ →参考备注

二阶段锁的改进和变种： 协调者备份、超时机制→三阶段提交协议、树形2PC协议（或称递归2PC协议）、动态2阶段提交协议（D2PC） ……

2）基于消息通知的分布式事务：最终一致性的2）基于消息通知的分布式事务：最终一致性的

分布式锁： ZooKeeper分布式锁服务：http://www.cnblogs.com/shanyou/archive/2012/09/22/2697818.html 分布式join：小表广播相同的切分条件：将同一个用户的数据放在一起异构复制

分布式分页： 写时有序（单机没问题），但多台机器一定会有热点 Map-Reduce：写时保证各个节点有序，上层做归并

无处不在的…… （PASS）

无处不在的缓存 cpu中的L1 Cache/L2 Cache、memmcahe、sqlserver中的存储过程的预编译、 Aps.net中页面输出缓存、浏览器中css/js/img资源的缓存…… 从生活到技术、从整体到局部 • 为什么需要缓存 • 因为从生活到技术的各个方面存在着不对等，不对等的计算能力，不对等的传输速率，不对等的成本…… • 缓存最关键指标 • 命中率

无处不在的队列 无处不在的异步无处不在的超时 …… 所有这些，目的都是提高系统的鲁棒性和稳定性。

互联网系统的稳定性保证

没有百分百稳定的系统，即使是Google做到了5个9，也就是说每年还会有5分多钟的不可用。没有百分百稳定的系统，即使是Google做到了5个9，也就是说每年还会有5分多钟的不可用。那什么是稳定的互联网系统？少出问题、快速解决、清楚系统的健康趋势…… 有哪些指标？响应时间、响应性、等待时间、吞吐率、负载、负载敏感度、效率、容量、可伸缩性……→ →参看备注

如何做？ • SLA保证 • Design for Failure • 分层隔离 • 可运维 • 可测试 • 全面的监控

SLA保证（去哪儿网） • “SLA：Service-Level Agreement的缩写，意思是服务等级协议。是关于网络服务供应商和客户间的一份合同，其中定义了服务类型、服务质量和客户付款等术语。 • 其实就是服务提供者对自己提供的服务质量的保证，一种外部的约束。

Design for Failure 具体点：到我们实际编码中各种异常处理本质也是种Design for failure的思想

Design for Failure Failover策略： 1）服务降级：保证核心功能，其实最容易想到的就是配置文件中的一大堆开关。 OSSP灰度控制方案：也是可以在出现异常情况下进行降级服务，不过不是非常的及时。 2）快速失败：保证不卡死，最容易理解的就是配置文件中的各种超时配置，访问数据库超时、访问缓存超时、记录日志到mongodb超时……

Design for Failure Failover策略： 3）心跳、重试、热切换：nginx热备。不过要谨慎重试，否则可能会导致雪崩效应。

分层隔离 • 1）接入方式隔离：三网隔离，3G、wifi、电信、联通、移动…… • 2）按业务隔离：OSSP接口、日志接口、灵犀语音交互接口、灵犀客户端接口、广州灵犀业务服务器、北京灵犀业务服务器…… • 3）按功能核心程序隔离 • 其他维度……

可运维 • 1）容灾预案：IDC容灾、快速扩容（Sacle out） • 2）流量控制、限流降级 • 3）配置通过页面集中管理，比如OSSP正在做的信源平台 • …… • 架构师要具备运维人员的素质。

可测试 • 上线之前能够准确的评估系统的性能，去哪儿网有一个模拟真实现网环境的测试系统：Touchstone（试金石系统）→ →利用tcpcopy将现网的真实流量复制到测试系统http://blog.csdn.net/wangbin579/article/category/926096 • 值得OSSP学习。 • 全面的监控 • 上线后需要能清楚系统的健康状况，对故障排查和架构演进都至关重要。

写在最后： “还记得吗？”“全都记得。”“现在呢？”“已经忘却了一小半。”“啊，已经忘了一大半。”“不坏不坏，忘得真快，那么现在呢？”“已经全都忘了，忘得干干净净。

谢谢大家！

阿里技术嘉年华 - aDev 内容感悟