网站微服务架构最佳实现.docx

? ? ? ? ? ? ? ? 网站的微服务架构最佳实现 ? ? ? ? ? ?? ? ? ? ? ? ? ? ? ? ? ? 微服务架构的目标是帮助工程团队更快、更安全、更高质量地交付产品。拆分服务允许团队快速迭代的同时，保证了对系统剩余部分的最小影响。 在Medium，我们的技术堆栈始于2012年的单体Node.js应用程序。我们已经构建了几个卫星服务，但我们还没有制定一个系统地采用微服务架构的策略。 随着系统变得越来越复杂并且团队不断发展，我们在2018年初转向了微服务架构。在这篇文章中，我们希望分享我们有效地做到这一点并避免微服务综合症的经验。 什么是微服务架构？ 首先，让我们花一点时间来思考微服务架构应该是怎么样到，不应该是怎么到。 “微服务”是解决那些过载和混乱的软件工程的手段之一。 我们在Medium至少这样认为： 在微服务架构中，多个松散耦合的服务协同工作。 每项服务都专注于一个目的，并具有相关行为和数据的高度凝聚力。 该定义包括三个微服务设计原则： 单一职责 - 每项服务应专注于一个目的并做得好。 松耦合 - 服务对彼此知之甚少。 对一项服务的更改不应要求更改其他服务。 服务之间的通信应仅通过公共服务接口进行。 高内聚性 - 每项服务将所有相关行为和数据封装在一起。 如果我们需要构建新功能，则所有更改应仅本地化为一个服务。 当我们对微服务进行构建模型时，我们应该遵守所有三个设计原则。 这是实现微服务架构全部潜力的唯一途径。 错过任何一个都会成为反模式。 如果缺少单一职责，每个微服务最终会做太多事情，成长为多个“单体”服务。 我们不会从微服务架构中获得全部好处，我们也会支付运营成本。 如果缺少松散耦合，对一个服务的更改会影响其他服务，因此我们无法快速安全地发布更改，这本应该是微服务架构的核心优势。 更重要的是，紧密耦合引起的问题可能是灾难性的，例如数据不一致甚至数据丢失。 如果缺少高凝聚力，我们将最终得到一个分布式单体系统 - 一组混乱的服务，必须同时进行更改和部署才能构建单一功能。 由于多个服务协调的复杂性和成本（有时跨多个团队），分布式单体系统通常比集中式单体系统差得多。 于此同时，认识到微服务不应该长成那样，也同样重要： 微服务不是具有少量代码行或“微”任务的服务。 这种误解来自“微服务”这个名字。 微服务架构的目标不是拥有尽可能多的小型服务。 只有符合上述三项原则，服务的提炼就是恰当的。 微服务不是一直使用新技术构建的服务。 尽管微服务架构允许团队更轻松地测试新技术，但它并不是微服务架构的主要目标。 只有从接偶的服务中受益，团队才能使用完全相同的技术堆栈去构建新到服务。 微服务不是必须从头开始构建的服务。 如果您已经拥有一个架构良好的单一应用程序，请避免养成从头开始构建每个新服务的习惯。 可能有机会直接从单体服务中提取逻辑。 同样，上述三个原则应该仍然有效。 为什么是现在？ 在Medium，我们总是在做出重大产品或工程决策时会问“为什么是现在？”这个问题。 “为什么？”是一个显而易见的问题，但它假设我们拥有无限的人，时间和资源，这是一个危险的假设。 当你想到“为什么是现在？”时，你突然有了更多的限制 - 对当前工作的影响，机会成本，分心的开销等等。这个问题有助于我们更好地优先考虑。 我们现在需要采用微服务的原因是我们的Node.js单体应用程序已经成为瓶颈。 首先，最紧迫和最重要的瓶颈是其性能。 某些计算量很大且I / O很重的任务不适合Node.js. 我们一直在逐步改进整体应用程序，但事实证明它是无效的。 它的低劣性能使我们无法提供更好的产品而不会使已经非常慢的应用程序变慢。 其次，重要且有点紧迫的瓶颈是单体应用程序会拖慢产品开发速度。 由于所有工程师都在单个应用程序中构建功能，因此它们通常紧密耦合。 我们无法灵活地改变系统的一部分，因为它也可能影响其他部分。 我们也害怕做出重大改变，因为影响太大，有时甚至难以预测。 整个应用程序作为一个整体进行部署，因此如果由于一次错误提交导致部署停滞，那么所有其他更改（即使它们完全正常工作）也无法顺利完成发布。 相比之下，微服务架构允许团队更快地开发和迭代。 因为这些功能与复杂系统是解耦的，所以工程师可以专注于他们正在构建的功能。 自然的，他们就可以轻易安全地做到重大变更。 在我们新的微服务架构中，功能修改后可以在一个小时内发布上线。同样的，工程师不必担心它会如何影响系统的其他部分。 项目组的团队还探索了在开发中安全使用生产数据的方法，这在多年前是无法实现的。 随着我们的工程团队的发展，我们有机会去突破现状。 第三，单块应用程序使系统很难针对特定任务进行扩展，也很难针对不同类型的任务分离资源问题。使用单一的单块应用程序，我们必须在整个系统上下扩展，以完成更需要资