转换到微服务架构时需要考虑的7件事

在本文中，我将详细介绍在转向微服务时需要考虑的内容，以及会面临的一些挑战。

从头新建的微服务项目

每当您的团队从头开始开发一个新的应用程序时，不需要陷入多年前做出的过时决策和继承技术债时，感觉很好。现在开发新应用的大多数团队可能会选择使用Docker，并采用微服务体系结构来实现速度和敏捷性。

然而，在你开始之前，有以下几点需要考虑：

1、独立程度

第一个决定是——你希望你的服务有多独立?你可选择下列其中一项：

• 每个服务都与自己的数据库和UI完全独立。这与极端的微服务体系结构是一致的，在这种体系结构中，服务实际上不共享任何东西，并且完全解耦。好的方面是，每个微服务的团队可以选择最适合他们需求的数据库。然而，这种方法使得确保所有数据存储都是同步和一致性变得更加困难。例如，您需要验证所有数据存储中都存在相同的UserIDs，并且其中任何一个都没有丢失。此外，每个团队都需要复制数据库管理任务(如备份)。
• 您可以选择共享一些组件，通常是您的数据库。这使得跨所有团队执行标准和确保跨所有服务的数据一致性变得更加容易。然而，这也意味着您的服务没有完全解耦，如果有人更新了数据表或schema,，其他服务也可能受到影响。

这两种方法都有利有弊，所以你需要决定你能接受什么。我们选择了第二种方法，因为我们不希望处理不一致的数据，然后花时间寻找方法来确保一致性。

2、代码组织结构

有几种方法可以组织代码库。您可以为每个服务创建一个存储库，您可以为所有服务创建一个“mono repo”，并为每个服务创建一个文件夹。我们选择mono repo方法。

3、技术栈

要为一个单体应用程序确定技术栈已经够困难了，但是现在必须为每个微服务选择技术栈。如果您的服务过于异构，那么在理论上看起来有吸引力的内容在实践中可能会出现问题。标准化会成为一个问题，牛仔行为（过于自由的选择）也有可能出现。而且，如果每个团队都使用完全不同的技术栈，那么在团队之间转换移动就更困难了。

我们建议采用一种平衡的方法，即在应用程序中存在首选的技术堆栈。如果任何团队想要覆盖这个默认堆栈，他们应该用赞成和反对的理由来证明他们的决定，为什么不同的堆栈更适合他们的微服务。您的技术堆栈应该包括编程语言、测试和日志框架、云提供程序、基础设施、存储和监视等。

4、操作的复杂性

微服务极大地增加了操作复杂性，因为您需要从非常基本的角度重新考虑操作。

你需要考虑以下方面：

• 基础设施：为微服务定义基础设施需求，然后为每个微服务提供和维护基础框架，这增加了一些复杂性，这是大多数操作系统的工程师所不习惯的。另外，随着这些服务的放大和缩小，基础设施需要自动提供和降低，因此您需要非常复杂的自动化级别。
• 负载平衡和扩展：您可能需要一个比单体应用程序复杂得多的扩展策略，而单体应用程序总是被扩展(x轴)。使用微服务，您将需要弄清楚是否需要扩展所有服务，或者在需求激增时只扩展一个子集。您的Ops团队需要了解y轴的扩展，因为微服务方法与it和z轴的扩展是一致的，从而获得x和y的好处。
• 服务发现：微服务世界中的服务实例的集合由于缩放和升级而动态变化。此外，服务具有动态的网络位置，因此您需要一种方法来发现新的服务实例。我们推荐像领事这样的服务登记处，因为它对我们很有效。阅读更多关于客户端服务发现、服务器端服务发现和常用服务注册的列表。
• 监视:必须对每个微服务进行配置和维护，这增加了Ops工程师的复杂性。此外，监视解决方案还必须处理一些场景，其中服务的子集是按比例伸缩的。

在您决定转向微服务之前，操作复杂性本身应该让您暂停一下。除非您意识到微服务的挑战，并有一个解决它们的计划，否则这将是一个痛苦的过渡。

5、持续交付

我们同意Martin Fowler的观点，他在他关于微服务权衡的博客文章中写道：

“能够迅速部署小型独立单元对开发来说是一个巨大的利好，但它给运营带来了额外的压力，因为6个应用程序现在变成了数 百个小微服务。许多组织会发现处理这样一群快速变化的工具是非常困难的。这加强了持续交付的重要作用。尽管持续交付对整 体而言是一项有价值的技能，但它几乎总是值得付出努力去获得的，对于一个严肃的微服务设置来说，这是必不可少的。“

使用微服务的公司，如Netflix和Amazon，有资源为他们的微服务构建自定义的持续交付管道。然而，并不是每个组织都能负担得起。即使您负担得起，您也应该考虑，您的时间是花在构建脆弱的、必须为每个微服务定制的自定义自动化上的最佳时间，还是您希望改进自己的产品。

你有三个选择：

• 确定您不希望支付微服务溢价，并保持单一体系结构
• 咬紧牙关，通过拼凑几个不同的工具来构建自己的管道，这些工具可以帮助处理工作流的某些部分。这种方法的问题在于，随着微服务的数量增加，自动化它们所需的时间和精力会以更快的速度增长。
• 使用像Shippable这样的CD自动化平台，可以为异构微服务提供90%以上的持续交付。

6、团队组织

最后但并非最不重要的是，您需要重新组织您的团队，以确保每个微服务都是独立地开发、部署和维护的。你不能让你的工程师在多个微服务上工作，因为这必然会导致一些决策的优化，而这些决策与对每一个微服务的最佳状态并不相关。

一个独立的、独立的团队应该处理每个微服务。亚马逊的团队模式——它应该足够小，即少于10人。在某些情况下，每个团队都应该在开发、测试、操作、DB管理、UX甚至产品管理等方面拥有专业知识。这并不意味着每个角色都需要一个独特的团队成员，只是需要在团队中解决它们。例如，DevOps工程师满足Dev和Ops的双重角色。类似地，每个团队也可以有一个编写spec和定义UX的经理。

上面的方法有一些变化，比如集中项目操作系统、产品管理或平台团队。这些文章进一步阐明了如何组织团队。

Microservices现有项目

如果您想将现有的整块集成到微服务中，您仍然需要考虑上面描述的所有要点。但是，还有一个针对您的情况的额外挑战。你将需要一种策略来帮助你在各个阶段进行过渡。

7、从单体架构到微服务的转换策略

这是一个广泛的话题，就像罗马不是一天建成的，你的过渡需要时间和专注。

简而言之，你需要做以下事情：

• 实现持续的交付，以便在服务数量开始增长时，您拥有适当的自动化
• 转移到像GitHub这样的分布式源代码控制系统，这样团队就可以独立地工作，而不会互相影响
• 采用Docker技术，使您的应用程序以获得可移植性，并能够在几秒钟内将服务向上和向下旋转
• 始终将新功能构建为微服务
• 逐步转换现有的组件，从最不复杂的业务功能开始，使用最少的依赖项，然后使用更复杂的功能。

总结

正如您所看到的，采用微服务并不是微不足道的，只有当您看到应用程序的足够价值时，才应该进行。