永别了，微服务架构！

0 前言

除非你一直生活在岩石下面，否则你可能已经知道微服务是当今盛行的架构趋势。与这一趋势一同成长，Segment早期就采用了这种最佳实践，这在某些情况下对我们很有帮助，但正如你将很快了解到的，在其他情况下则并非如此。
简单来说，微服务是一种面向服务的软件架构，其中服务器端应用程序通过组合许多单一用途、低开销的网络服务构建。微服务的好处包罗:

• 提高模块化
  
• 减少测试负担
  
• 改进功能组合
  
• 情况隔离
  
• 开发团队自治
  

与之相对的是单体架构，在单体架构中，大量功能存在于一个服务中，该服务作为一个单元进行测试、部署和扩展。
2017年初，我们的核心产品之一达到了一个临界点。看起来我们从微服务树上掉下来，遇到了每一个分支。小团队不仅没能更快推进工作，反而陷入不断增加的复杂性。微服务架构本质优势变成负担。开发速率急剧下降，缺陷率敏捷上升。
最终，团队发现自己无法取得希望，三名全职工程师大部分时间都在维持体系正常运行。须做出改变。本文报告了我们如何退一步，采用一种更符合我们产品需求和团队需求的方法。
1 微服务的优势

Segment的客户数据基础办法每秒处置惩罚数十万个事件并将其转发到合作伙伴的API，称之为服务器端目标地。有凌驾一百种如许的目标地，如Google Analytics、Optimizely或自定义webhook。
几年前，当产品首次推出时，架构非常简单。有一个API吸收事件并将其转发到一个分布式MQ。事件在这里指由Web或APP天生的JSON对象，包含有关用户及其行为的信息。
1.1 一个示例负载

当事件从队列中被消费时，会检查客户管理的设置以决定哪些目标地应吸收该事件。然后，事件依次发送到每个目标地的API，这对开发职员很有用，由于他们只需将事件发送到一个端点，即Segment的API，而无需构建多个集成。Segment负责向每个目标地端点发出请求。
若对某个目标地的请求失败，有时会尝试在稍后时间再次发送该事件。有些失败可重试，而有些不可：

• 可重试的错误是那些可能被目标地接受的错误，如HTTP 500、速率限制和超时
  
• 不可重试的错误是那些我们确定目标地永世不会接受的请求，如无效凭据或缺少必填字段的请求
  

此时，一个队列包含最新的事件及那些可能已重试多次的事件，涉及全部目标地，导致队首阻塞。即若一个目标地变慢或宕机，重试请求会充斥队列，导致全部目标地的耽误。
假设目标地X出现临时问题，每个请求都会超时。这不仅会创建一个大的请求积压，还会导致每个失败的事件在队列中重试。虽然我们的体系会自动扩展以应对增加的负载，但队列深度的突然增加会超出扩展能力，导致最新事件的耽误。全部目标地的交付时间都增加，由于目标地X出现短暂故障。客户依靠于交付的及时性，以是我们不能在管道的任何地方容忍等候时间的增加。

为解决队首阻塞，团队为每个目标地创建一个单独的服务和队列。这种新架构包罗一个额外的路由进程，该进程吸收入站事件并将事件的副本分发到每个选定的目标地。
如今，若一个目标地非常，只有其队列会积压，其他目标地不影响。如许的微服务架构将各目标地隔离，这在一个目标地频仍出现问题时尤其紧张。

2 独立代码库的理由

每个目标地API使用差别的请求格式，需要自定义代码将事件转换为匹配的格式。一个根本的例子是目标地X需要将生日发送为traits.dob，而我们的API接受traits.birthday。目标地X的转换代码可能如下：
许多当代目标地端点采用Segment的请求格式，使得某些转换相对简单。然而，这些转换可能非常复杂，具体取决于目标地API的结构。如一些较旧且庞大的目标地，我们需要将值插入手工制作的XML负载。
最初，当目标地被分成单独服务时，全部代码都在一个代码库。一个巨大挫折点是单个失败的测试会导致全部目标地的测试失败。当我们想部署一个更改时，纵然这些更改与初始更改无关，也须花时间修复失败的测试。为此，决定将每个目标地的代码拆分到各自代码库。全部目标地已分离成各自的服务，以是这一转变很天然。
拆分成独立的代码库使我们能够轻松地隔离目标地的测试套件。这种隔离使开发团队在维护目标地时能够快速行动。
3 扩展微服务和代码库

随时间推移，新增50多个新目标地，意味着50多个新代码库。为减轻开发和维护这些代码库的负担，创建共享库，以便在全部目标地之间简化常见的转换和功能，如HTTP请求处置惩罚。
如若想从事件获取用户的名字，可在任何目标地的代码中调用event.name()。共享库会检查事件中的属性键name和Name。若这些不存在，它会检查firstName、first_name和FirstName。对于姓氏，它会以相同方式检查这些属性，并将两个名字组合形成全名。
共享库使构建新目标地变得快捷。统一的一组共享功能带来的认识感使维护变得不再头疼。
3.1 新问题开始出现

测试和部署这些共享库的更改影响了我们全部的目标地。维护这些代码库需要大量精力。改进时，需要测试和部署几十个服务，这是高风险任务。时间紧迫时，工程师们只会在单个目标地的代码库中包含更新版本的共享库。
随时间推移，这些共享库的版本在差别目标地的代码库之间开始分化。我们曾在减少定制化方面的巨大优势开始逆转。最终，全部目标地都在使用差别版本的共享库。本可构建工具来自动化部署更改，但此时，不仅开发职员的生产力受到了影响，还遇到微服务架构其他问题。
另一个问题是
3.2  每个服务都有差别负载模式

一些服务天天处置惩罚少量事件，而其他服务每秒处置惩罚数千个事件。对于处置惩罚少量事件的目标地，每当负载出现意外峰值时，操作员必须手动扩展服务。
虽然有了自动扩展，但每个服务所需的CPU和内存资源差别，使得自动扩展配置更像是一门艺术而非科学。
随着目标地数量迅增，团队均匀每月增加三个目标地，这意味着更多代码库、更多队列和更多服务。微服务架构导致操作开销与增加的目标地数量成线性增长。因此，决定退一步，重新思考整个管道。
4 放弃微服务和队列

计划列表上的第一项是将如今凌驾140个服务归并为一个服务。管理全部这些服务的开销对我们的团队来说是一个巨大负担。我们的工程师经常由于负载峰值被唤醒，导致无法安睡。
然而，当时的架构使得迁移到单一服务变得具有挑战性。每个目标地都有一个单独的队列和服务。这意味着我们必须重构每个队列中的消息处置惩罚逻辑。我们决定从零开始构建一个新的目标地体系。
目标是创建一个单一的、共享的队列，全部事件在这里排队，并由一个共享的目标地处置惩罚器进行处置惩罚。新架构避免了我们在微服务架构中遇到的队首阻塞和队列深度增加的问题。

然而，当时的架构使得转向单一服务具有挑战性。由于每个目标地都有一个单独的队列，每个工作职员都必须检查每个队列的工作情况，这会给目标地服务增加一层复杂性，而我们对此感到不舒服。这是离心机的主要灵感。 Centrifuge 将取代我们全部的单独队列，并负责将事件发送到单个整体服务。
5 迁移到 Monorepo

鉴于只有一项服务，将全部目标代码移至一个存储库中是故意义的，即将全部差别的依靠项和测试归并到一个存储库中。我们知道这会很混乱。
对于 120 个独特依靠项中的每一个，我们致力于为全部目标地提供一个版本。当我们移动目标地时，我们会检查它正在使用的依靠项并将其更新到最新版本。我们修复了目标地中与新版本不符的任何内容。
通过这种转变，我们不再需要跟踪依靠版本之间的差别。全部的目标地都使用相同的版本，这显着低落了代码库的复杂性。如今，维护目标地变得更省时、风险更低。
我们还想要一个测试套件，使我们能够快速轻松地运行全部目标测试。在更新我们之前讨论的共享库时，运行全部测试是主要障碍之一。
幸运的是，目标地测试都有相似的结构。他们进行了根本的单元测试，以验证我们的自定义转换逻辑是否正确，并向合作伙伴的端点执行 HTTP 请求，以验证事件是否按预期显示在目标中。
6 复盘

将每个目标代码库分离到自己的存储库中的最初动机是为了隔离测试失败。然而，事实证明这是一个虚伪的优势。发出 HTTP 请求的测试仍然经常失败。由于目标地被分成自己的存储库，因此没有动力去清理失败的测试。这种糟糕的卫生状况导致了令人沮丧的技术债务的持续来源。通常，原本只需要一两个小时的小改变最终需要几天到一周的时间才气完成。
7 构建弹性测试套件

测试运行期间对目标端点的出站 HTTP 请求是测试失败的主要原因。诸如逾期凭证之类的不相关问题不应导致测试失败。根据履历，我们还知道某些目标端点比其他端点慢得多。某些目标地需要长达 5 分钟的时间来运行测试。对于 140 多个目标地，我们的测试套件可能需要长达一个小时才气运行。
为了解决这两个问题，我们创建了 Traffic Recorder。 Traffic Recorder构建在yakbak之上，负责纪录和生存目标地的测试流量。每当测试第一次运行时，任何请求及其相应的响应都会纪录到文件中。在后续测试运行中，将回放文件中的请求和响应，而不是请求目标端点。这些文件被签入存储库，以便测试在每次更改中保持同等。如今测试套件不再依靠于互联网上的这些 HTTP 请求，我们的测试变得更加有弹性，这是迁移到单个存储库的必备条件。
我记得在我们集成了 Traffic Recorder 之后，第一次对每个目标地进行了测试。我们花了几毫秒的时间才完成对全部 140 多个目标地的测试。过去，只需几分钟即可完成一个目标地。感觉就像魔法一样。
8 单体体系的工作原理

一旦全部目标地的代码都集中在一个版本库中，它们就可以归并到一个服务中。由于每个目标地都在一个服务中，我们的开发职员的工作效率大大提高。我们不再需要为了修改一个共享库而部署 140 多个服务。一名工程师就能在几分钟内部署服务。
速率的提高就是最好的证明。2016 年，当我们的微服务架构还在运行时，我们对共享库进行了 32 次改进。就在今年，我们进行了 46 项改进。在过去 6 个月中，我们对库的改进比 2016 年整年都要多。
这一变革也让我们的运营故事受益匪浅。由于每个目标地都在一个服务中，我们拥有 CPU 和内存密集型目标地的良好组合，这使得扩展服务以满足需求变得更加容易。庞大的工人池可以吸收峰值负载，因此我们不再为处置惩罚少量负载的目标地分页。
9 Trade Offs

从我们的微服务架构转变为单体架构总体上是一个巨大的进步，但是，这其中也有取舍：

• 故障隔离很困难。由于全部服务都在单体中运行，如果某个目标地出现错误导致服务瓦解，那么全部目标地的服务都会瓦解。我们有全面的自动测试，但测试只能到此为止。我们目前正在开发一种更强盛的方法，以防止一个目标地导致整个服务宕机，同时仍将全部目标地保持在一个整体中
  
• 内存缓存的效果较差。以前，由于每个目标地只有一个服务，我们的低流量目标地只有少量进程，这意味着其控制平面数据的内存缓存会一直处于热状态。而如今，缓存分散在 3000 多个进程中，被攻击的可能性大大低落。我们可以使用像 Redis 如许的东西来解决这个问题，但这又是一个我们必须考虑的扩展问题。最终，考虑到可观的运行效益，我们接受了这种效率损失
  
• 更新依靠关系的版本可能会粉碎多个目标地。虽然将全部内容转移到一个版本库中解决了之前依靠关系混乱的问题，但这也意味着如果我们想使用最新版本的库，就有可能需要更新其他目标地才气使用新版本。不过我们认为，这种方法的简便性值得衡量利弊。有了我们全面的自动测试套件，我们就能快速了解更新依靠版本后会出现哪些问题
  

8 总结

我们最初的微服务架构运行了一段时间，通过将目标地相互隔离，解决了管道中的直接性能问题。但是，我们的架构并不适合扩展。在需要进行批量更新时，我们缺乏测试和部署微服务的适当工具。因此，我们的开发职员工作效率敏捷下降。
转向单体后，我们摆脱了管道的运行问题，同时显著提高了开发职员的工作效率。但我们并没有草率地完成这一转变，我们知道要想乐成，我们必须考虑一些事情。
我们需要一个坚如磐石的测试套件，将全部东西都放到一个 repo 中。如果不如许做，我们就会陷入与最初决定将它们分开时同样的境地。过去，不断失败的测试损害了我们的工作效率，我们不希望这种情况再次发生。
我们接受了单体架构中固有的取舍，并确保为每种架构编写了一个好故事。我们必须接受这种改变所带来的一些牺牲。
在决定使用微服务照旧单体架构时，需要考虑的因素各有差别。在我们基础架构的某些部分，微服务运行良好，但我们的服务器端目标地是一个美满的例子，说明了这种盛行趋势现实上会损害生产率和性能。事实证明，我们的解决方案是单体。
关注我，紧跟本系列专栏文章，咱们下篇再续！

作者简介：魔都技术专家，多家大厂后端一线研发履历，在分布式体系、和大数据体系等方面有多年的研究和实践履历，拥有从零到一的大数据平台和基础架构研发履历，对分布式存储、数据平台架构、数据堆栈等领域都有丰富实践履历。
各大技术社区头部专家博主。具有丰富的引领团队履历，深厚业务架构和解决方案的积累。
负责：

• 中央/分销预订体系性能优化
  
• 活动&优惠券等营销中台建设
  
• 交易平台及数据中台等架构和开发设计
  
• 车联网核心平台-物联网连接平台、大数据平台架构设计及优化
  

目前主攻低落软件复杂性设计、构建高可用体系方向。

参考：

• 编程严选网
  

本文由博客一文多发平台 OpenWrite 发布！

免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。