12.17 Day 2 - 从亚马逊的实践，谈分布式系统的难点

大家好，我是 Snow Hide，作为《左耳听风》这个专栏的学员之一，这是我打卡的第 2 天，也是我第 2 次进行打卡这种操作。

今天我温习了该专栏里一篇叫《从亚马逊的实践，谈分布式系统的难点》的文章。

关键词总结：服务接口、亚马逊的应用架构规定、分布式架构问题、分布式架构方案、分布式架构关注点。

 

所学总结：

 

亚马逊的应用架构规定

• 所有模块的功能或返回值都要以服务接口的形式出现。
• 要通过开放的服务接口进行应用模块之间的通信。
• 应用之间必须以并且只能以服务接口的形式进行通信。
• 不排斥所使用的技术，包括但不限于主流或自定义通信协议。
• 所有的服务接口都要能服务于其他包括来自外界的应用。
• 违反以上任意一条者，将会被辞退。

 

分布式架构问题

• 线上故障所产生的工单将在服务各异的团队中辗转反复。
• 服务之间在没有配额或限流时有遭受洪流攻击的潜在风险。
• 在没有健壮且适用的监控系统时，追踪和排错将异常复杂。
• 系统对发现服务和发现之后进行管理的相关操作也相当复杂。

 

分布式架构方案

分布式架构团队

分布式架构里的每一个服务都由一个独立的小团队（不宜多于 16 人）来按职责分工并执行从开发到部署到维护的整个生命周期。

分布式架构排错

分布式架构里的任意服务一旦出现错误时，该服务的所属团队成员需要同时出动，各自排查自己负责的部分，直到问题被解决为止。

分布式架构责任

分布式架构团队里的每一个人都要负责维护自己的产物，让团队里的成员一起体会生产容易维护不易这个道理。

分布式架构运维

分布式架构系统中服务间的运维半自动化或全自动化将有助于提高整个团队在将来的产能，同时还能降低因人工操作而导致的出错率。

分布式架构复用性

分布式架构中的内部或外部服务将被一视同仁，内部服务在各方面的考量都将和外部服务类似，在设计之初就做好了可以安全地让外部服务调用的准备。

 

分布式架构关注点

服务间的协作性问题

• 不统一的技术栈：技术各异的服务之间各自的行为差异可能会提升系统在架构过程中的难度。
• 不兼容的通信方式：在没有规范的情况下，不同的服务之间可能会使用不同甚至无法相互兼容的通信协议。
• 不相符的响应格式：在没有使用例如 Swagger 这样的 API 规范时，服务之间各自的响应格式可能会有比较大的差异。
• 不协调的开发过程和运维方式：在没有做好分层管理的情况下，开发者容易接触到只有运维人员熟悉的区域。例如开发者的职责范围是业务应用层，但由于职责划分不清晰而导致他们可以执行原本只有专业的运维人员才可能做的操作。

服务间的依赖性问题

分布式系统中会经常遇到的两种效应：多米诺骨牌效应和木桶短板效应。

多米诺骨牌效应

由于一个服务产生了问题，从而导致对其有所依赖的服务均处于不可用状态的情况。

木桶短板效应

整个系统的可用性将取决于最容易出错的那个服务。

数据存取范围

服务要通过分配给各自的数据库来存取数据，以避免当数据库出错时所有服务都不可用的情况。

服务间的故障率问题

分布式系统中出故障的几率要比单体应用高，所以服务所属团队在设计其服务时需要考虑降低该服务在出错时恢复运作的时间和成本，也即 Design for Failure（故障假设设计）。

服务间的复杂度问题

系统复杂度分布在四个层面，这四个层面分别为：基础层、平台层、应用层、接入层。

基础层（硬件设施）

基础层可以由服务器硬件、网络以及存储等设备所组成。

平台层（中间件）

平台层可以由 Servlet 服务器、关系型数据库、缓存数据库、消息队列中间件所组成。

应用层（业务系统）

应用层可以由实现了业务所对应的功能服务所组成。

接入层

接入层可以由网关、负载均衡、内容分发网络以及域名系统所组成。

层间可能会产生的问题

• 层间产生的问题将波及整个系统：
  • 涟漪效应：多个同时一起瘫；
  • 多米诺骨牌效应：一个接一个的瘫。
• 没有统一的运维管理视图会提升各层的维护难度。

 

末了

重新总结了一下文中提到的内容：亚马逊在分布式服务系统方面的实践和经验积累所获取的成效、分布式系统中需要注意的几个问题以及方案。