散布式系统的难点 亚马逊的通常

疑问一：异构系统的不规范疑问

在软件开发和运维环节中，存在许多规范化疑问。例如，软件和运行不足一致的规范，通讯协定和数据格局各不相反，开发和运维的环节和方法也不分歧。不同的软件和编程言语带来了不同的兼容性疑问，以及各自不同的开发、测试、运维规范。这种差异造成咱们在开发和运维时驳回不同的方法，从而参与了架构的复杂度。

举例来说，有的软件须要经过修正 .conf 文件来更改性能，而另一些则须要调用控制 API 接口。在通讯方面，不同软件驳回不同的协定，即使在相反的网络协定中，也或者出现不同的数据格局。不同的技术团队由于经常使用了不同的技术栈，也会造成开发和运维方式的多样化。这些差异都会使咱们的散布式系统架构变得极端复杂。因此，散布式系统架构须要制订相应的规范。

例如，我留意到许多服务的 API 前往失误时不经常使用 HTTP 的失误形态码，而是前往 HTTP 200，而后在照应体（HTTP Body）中的 JSON 字符串中蕴含相似 “error, bla bla error message” 的失误信息。这种设计不只反直觉，而且极大地影响了监控的成功。实践上，如今应该经常使用 Swagger 等规范来规范化 API。

另一个例子是性能控制。很多公司在软件性能控制中只是驳回便捷的 key-value 方式，这种灵敏性虽然很高，但也很容易被滥用。例如，不规范的性能命名，不规范的值，甚至在性能中间接嵌入前端展现内容。一个正当的性能控制当分为三层：底层和操作系统相关，两边层和两边件相关，最高层则是业务运行相关。底层和两边层的性能不应让用户轻易修正，而是经过模板选用。比如，操作系统相关的性能应构成规范模板供用户选用，而非轻易修正。只要当性能控制构成了规范，咱们才干有效控制各种系统的复杂性。

再比如，数据通讯协定通常包括协定头和协定体。协定头定义了基本的协定数据，而协定体则蕴含业务数据。咱们须要在协定头的定义上制订严厉的规范，以便一切经常使用该协定的团队都遵照同一套规定。这种规范化能够协助咱们更好地启动恳求监控、调度和控制。

经过这些规范化措施，咱们可以更好地控制散布式系统的复杂度，提高系统的可保养性和稳固性。

疑问二：系统架构中的服务依赖性疑问

在传统的单体运行中，假设某台主机宕机，整个运行就会中止运转。但是，这并不象征着散布式架构下就不会出现相似的疑问。在散布式系统中，各个服务之间通常存在依赖相关。当依赖链上的某个服务出现缺点时，或者会引发“多米诺骨牌”效应，造成一系列连锁反响。因此，在散布式架构中，服务的依赖相关也或者带来许多疑问。

一个典型的状况是，非关键业务被关键业务依赖，结果造成非关键业务变得像关键业务一样关键。服务依赖链中常会出现“木桶效应”，即整个系统的服务水平协定（SLA）由体现最差的那个服务所选择。这属于服务控制的领域。有效的服务控制不只要求咱们定义每个服务的关键水平，还须要明晰地定义和形容关键业务的关键调用门路。没有这样的控制和控制措施，咱们将难以有效地运维和控制整个系统。

须要特意留意的是，虽然许多散布式架构在运行层面做到了业务隔离，但在数据库层面却没有。假设一个非关键业务由于数据库疑问而造成整个数据库负载过高，或者会拖垮整个系统，造成全站无法用。因此，在数据库层面也须要启动相应的隔离。最佳通常是每条业务线经常使用独立的数据库。这也是亚马逊主机的通常之一：系统之间制止间接访问对方的数据库，只能经过服务接口启动交互。这种做法合乎微服务架构的要求。

总而言之，咱们不只要拆分服务，还须要为每个服务调配独立的数据库，从而防止不同服务之间相互搅扰。这样才干真正成功业务隔离，优化系统的牢靠性和稳固性。

疑问三：缺点出现的概率更大

在散布式系统中，由于经常使用的机器和服务数量庞大，缺点出现的概率比传统的单体运行更高。虽然散布式系统可以经过隔离来减小缺点的影响范围，但由于组件单一、结构复杂，缺点的出现频率反而更高。另一方面，由于控制难度大，系统架构全貌难以把握，因此失误更容易出现。关于散布式系统的运维而言，这简直是噩梦般的应战。随着期间的推移，咱们会逐渐意识到以下几点：

运维团队在散布式系统中面临渺小的压力，简直时辰都在处置各种大小不一的缺点。很多大公司试图经过参与少量的监控目的来应答这些疑问，有时甚至设置了几万个监控点。但这种做法实践上是“蛮力”战略。一方面，过多的信息会造成信息过载，反而难以失掉有价值的洞察；另一方面，服务水平协定（SLA）要求咱们定义关键目的（Key Metrics），即最为关键的性能和形态目的。但是，很多公司在实践操作中漠视了这一点。

这种做法反映了运维思想上的惰性，由于它只关注“救火阶段”而不是“防火阶段”。正所谓“防火胜于救火”，咱们须要在设计和运维系统时预先思索缺点的出现，即所谓的“设计即为容错”（Design for Failure）。在系统设计中，就招思索如何减轻缺点的影响。假设无法齐全防止缺点，也应经过智能化手腕尽快复原缺点，将影响控制在最小范围内。

随着系统中机器和服务数量的参与，咱们会发现人类的局限性逐渐成为控制的瓶颈。人类无法对复杂系统启动面面俱到的控制，这时，智能化手腕就显得尤为关键。“人控制代码，代码控制机器，人不间接收理机器”，这一理念象征着咱们应经过智能化和代码控制来控制散布式系统的复杂性，将人的作用集中在控制代码和战略上，而将详细的系统操作交由智能化系统口头。这种方式不只能够优化系统的稳固性和可控性，还能有效减轻运维团队的累赘。

疑问四：多层架构的运维复杂度更大

通常状况下咱们可以将系统分为四个档次：基础层、平台层、运行层和接入层。

关于这四个档次，咱们须要明白一点：恣意一层出现疑问，都会影响整个系统的运转。假设没有一个一致的视图和控制机制，各层的运维就会被割裂，造成更大的复杂性。

许多公司在团队分工上是依照技艺启动划分的，比如产品开发、两边件开发、业务运维、系统运维等子团队。这种分工方式会造成每个团队只关注自己担任的部分，形成整个系统不足协同，信息不畅。当某个环节出现疑问时，整个系统就像“多米诺骨牌”一样，一个缺点会引发连锁反响，影响范围始终扩展。

由于不足一致的运维视图，团队无法分明地了解一个服务调用在每个档次和资源中是如何流转的。因此，当出现缺点时，定位疑问和沟通协调会消耗少量期间和精神。此前我在某云平台上班时曾遇到过相似的状况：从接入层到负载平衡，再到服务层和操作系统层，每个环节的 KeepAlive 参数设置不分歧，造成软件的实践运转行为与文档形容不符。工程师在排查疑问的环节中每每受挫，以为处置了一个疑问，结果又出现了新的疑问。经过屡次重复排查和调试，最终才将一切 KeepAlive 参数设置成分歧，消耗了少量期间。

由此可见，分工自身不是疑问，疑问在于分工后的单干能否一致和规范。这一点尤其值得注重。在系统运维中，确保各档次之间的协调分歧、规范化控制以及对系统的全体视图把握，是防止运维凌乱、提高效率和系统稳固性的关键。