微服务发展的利弊分析.docx

? ? ? ? ? ? 微服务发展的利弊分析 再见微服务，从100多个问题儿童到一个超级明星 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? 注：下文说的目的地就是对应的不同的数据平台（例如Google Analytics， Optimizely） 除非你生活在石器时代，不然你一定知道「微服务」是当世最流行的架构。我们Segment早在2015年就开始实践这一架构。这让我们在一些方面上吃了不少甜头，但很快我们发现：在其他场景，他时不时让我们吃了苦头。 简而言之，微服务的主要宣传点在于：模块化优化，减少测试负担，更好的功能组成，环境独立，而且开发团队是自治的（因为每一个服务的内部逻辑是自洽且独立的）。而另一头的单体应用：「巨大无比且难以测试，而且服务只能作为一个整理来伸缩（如果你要提高某一个服务的性能，只能把服务器整体提高）」 2017 早期，我们陷入了僵局，复杂的微服务树让我们的开发效率骤减，并且每一个开发小组都发现自己每次实现都会陷入巨大的复杂之中，此时，我们的缺陷率也迅速上升。 最终，我们不得不用三个全职工程师来维护每一个微服务系统的正常运行。这次我们意识到改变必须发生了，本文会讲述我们如何后退一步，让团队需要和产品需求完全一致的方法。 为什么微服务曾经可行？ Segment 的客户数据基础设施吸收每秒成百上千个事件，将每一个伙伴服务的API 请求结果一个个返回给对应的服务端的「目的地」。而「目的地」有上百种类别，例如Google Analytics， Optimizely，或者是一些自定义的webhook。 几年前，当产品初步发布，当时架构很简单。仅仅是一个接收事件并且转发的消息队列。在这个情况下，事件是由Web或移动应用程序生成的JSON对象，例子如下： { type: identify, traits: { name: Alex Noonan, email: anoonan@, company: Segment, title: Software Engineer }, userId: 97980cfea0067} 事件是从队列中消耗的，客户的设置会决定这个事件将会发送到哪个目的地。这个事件被纷纷发送 到每个目的地的API，这很有用，开发人员只需要将他们的事件发送到一个特定的目的地——也就是 Segment 的API，而不是你自己实现几十个项目集成。 如果一个请求失败了，有时候我们会稍后重试这个事件。一些失败的重试是安全的，但有些则不。可重试的错误可能会对事件目的地不造成改变，例如：50x错误，速率限制，请求超时等。不可重试的错误一般是这个请求我们确定永远都不会被目的地接受的。例如：请求包含无效的认证亦或是缺少必要的字段。 此时，一个简单的队列包含了新的事件请求以及若干个重试请求，彼此之间事件的目的地纵横交错，会导致的结果显而易见：队头阻塞。意味着在这个特定的场景下，如果一个目的地变慢了或者挂掉了，重试请求将会充斥这个队列，从而整个请求队列会被拖慢。 想象下我们有一个?目的地 X?遇到一个临时问题导致每一个请求都会超时。这不仅会产生大量尚未到达目的地 X的请求，而且每一个失败的事件将会被送往重试的队列。即便我们的系统会根据负载进行弹性伸缩，但是请求队列深度突然间的增长会超过我们伸缩的能力，结果就是新的时间推送会延迟。发送时间到每一个目的地的时间将会增加因为目的地X 有一个短暂的停止服务（因为临时问题）。客户依赖于我们的实时性，所以我们无法承受任何程度上的缓慢。 为了解决这个队头阻塞问题，我们团队给每一个目的地都分开实现了一个队列，这种新架构由一个额外的路由器进程组成，该进程接收入站事件并将事件的副本分发给每个选定的目标。现在如果一个目的地有超时问题，那么也仅仅是这个队列会进入阻塞而不会影响整体。这种「微服务风格」的架构分离把目的地彼此分开，当一个目的地老出问题，这种设计就显得很关键了。 个人Repo 的例子 每一个目的地的API 的请求格式都不同，需要自定义的代码去转换事件来匹配格式。一个简单的例子：还是目的地X，有一个更新生日的接口，作为请求内容的格式字段为?dob?，API 会对你要求字段为?birthday，那么转换代码就会如下： const traits = {} traits.dob = segmentEvent.birthday 许多现代的目的地终点都用了Segment 的请求格式，所以转换会很简单。但是，这些转换也可能会 十分复杂，取决于目的地API 的结构。 起初，目的地分成几个拆分的服务的时候，所有的代码都会在一个repo 里。一个巨大的挫折点就是一个测试的失败常常会导致整个项目测试无法跑通。我们可能会为