微服务与单体式架构

组织可以从单体式架构或微服务架构中受益，具体取决于多个因‘素。采用单体式架构进行开发，其主要优点是开发速度快，因为应用是基于一个代码库，比较简便。

单体式架构的优点包括：

易于部署 — 只有一个可执行文件或目录，部署更加简便。

开发 — 使用一个代码库构建应用时，开发难度较低。

性能 — 在集中式代码库和存储库中，一个 API 通常可以执行微服务架构中由多个 API 执行的相同功能。

测试简单 — 由于单体式应用是一个集中式单元，因此端对端测试的执行速度比分布式应用的测试速度更快。

调试轻松 — 所有代码均存放于一处，因而可以更轻松地跟踪请求并查找问题。

正如 Netflix 案例所示，单体式应用可能会非常有效，直至它们变得过于庞大并且难以扩展。单一功能中的细微更改也需要编译和测试整个平台，这与当今开发人员热衷的敏捷方法背道而驰。

单体式架构的缺点包括：

开发速度较慢 — 庞大的单体式应用会使开发复杂度上升、速度减慢。

可扩展性 — 您无法扩展个别组件。

可靠性 — 如有任何模块出现错误，整个应用的可用性就可能会受到影响。

阻碍技术采用 — 框架或语言的任何变动都会影响整个应用，从而使更改常常变得既昂贵又耗时。

缺乏灵活性 — 单体受到其本身已用技术的局限。

部署 — 对单体式应用的细微更改需要重新部署整个整体架构。

微服务架构（也可简称为微服务）是一种依赖于一系列可独立部署服务的架构方法。这些服务有自己的业务逻辑和数据库，并负责实现特定的目标。更新、测试、部署和扩展都在每一项服务中进行。微服务可将特定于领域的主要业务问题分解为单独的独立代码库。微服务不会降低复杂性，但它们可将任务划分成彼此独立运行且对整体有益的较小流程，从而使任何复杂情况都变得一目了然且更易管理。

微服务通常与 DevOps 并驾齐驱，因为它们是持续交付实践的基础，可让团队快速适应用户需求。

在 Jira 和 Confluence 遭遇增长和扩展挑战后，Atlassian 于 2018 年走上了微服务道路。我们发现，在本地运行的单租户、单体式架构无法通过扩展来满足未来需求。

我们决定重新架构 Jira 和 Confluence，将它们从有状态、单租户的单体式系统迁移到由 Amazon Web Services (AWS) 托管的无状态、多租户的云应用。接着，我们逐渐将它们分解为微服务。此项目被命名为 Vertigo，因为一位高级工程师曾表示，“我虽然非常喜欢这个主意，但它也真的会让我晕头转向。”这是我们迄今为止规模最大的基础架构项目，共花费两年时间完成向 AWS 过渡，并在短短 10 个月内迁移 100,000 多名客户，而且服务从未中断。此外，我们也致力于将相关服务分解为微服务。

微服务绝非灵丹妙药，但它们为成长中的软件和公司解决了许多问题。微服务架构由独立运行的单元构成，因此可在不影响其他服务的前提下开发、更新、部署和扩展各项服务。软件更新可以更为频繁，从而提升可靠性、正常运行时间和性能。我们从每周推送一次更新变成了每天两到三次。

随着 Atlassian 的成长，微服务使得我们能够通过按服务所有权进行划分从而更稳定地扩展团队和地理位置。在启动 Vertigo 项目前，Atlassian 在全球拥有五个开发中心。这些分散的团队受到集中式单体的限制，我们需要以自主的方式为他们提供支持。微服务让我们做到了这点。

Vertigo 带来的好处包括加快部署速度、灾难恢复、降低成本，以及提高性能。我们能够更快地实现目标，同时为客户提供更多的增量价值。

此外，更宽泛而言，微服务可让团队通过持续集成和持续交付 (CI/CD)更轻松地更新代码并加快发布周期。团队可以试验代码，并在出现问题时回滚。

简而言之，微服务的优点包括：

敏捷 — 提倡通过小型团队进行敏捷开发，频繁地进行部署。

灵活扩展 — 如果某一微服务达到负载容限，可将该服务的新实例快速部署到相关集群，以帮助缓解压力。我们现在采用多租户和无状态结构，客户分散在多个实例上，而且也能支持规模大得多的实例。

持续部署 — 我们现在拥有频繁且更快的发布周期。原先是每周推出一次更新，现在则可做到每天大约两三次。

高可维护性和可测试性 — 团队可以试验新的功能，并在出现状况时回滚。这样，代码更新变得更加轻松，新功能的面市时间也得以加快。此外，还可以轻松隔离和修复各项服务中的错误和漏洞。

独立部署 — 由于微服务是单独的单元，因此能够快速、轻松地独立部署各个功能。

技术灵活 — 微服务架构允许团队自由选择所需的工具。

高度可靠 — 您可以为特定服务部署更改，而不必担心要关闭整个应用。

团队情绪更高涨 — 使用微服务的 Atlassian 团队更加愉悦，因为他们更具自主性，可以自行构建和部署，而不必花费数周来等待拉取请求获得批准。

当我们从少量单体式代码库转变为更多分布式系统和服务为我们产品提供支持后，出现了意想不到的复杂性。我们最初竭力添加新的功能，保持与过去相同的速度和信心。微服务可能会使复杂性上升，从而导致开发蔓延或增长加快且无法管理。确定不同组件之间的关系、特定软件组件的负责人，或者如何避免干扰依赖组件，这些都可能非常棘手。

借助 Vertigo 项目，我们打造了一个通用功能，它可为我们的现有产品以及日后收购和制造的产品提供支持。如果您的公司产品单一，那么或许不需要微服务。

微服务的缺点可能包括：

开发蔓延 — 与单体式架构相比，微服务会导致复杂性上升，因为多个团队会在更多地方创建更多服务。开发蔓延若管理不当，则会导致开发速度减慢和运营绩效降低。

基础架构成本呈指数级增长 — 每项新的微服务都有自己的成本，例如在测试套件、部署手册、托管基础架构和监控工具等方面。

组织开销增多 — 团队需要额外的通信和协作来协调更新和交互。

调试挑战 — 每个微服务都有自己的一组日志，从而使调试变得更加复杂。此外，单个业务流程可能会在多个计算机上运行，从而进一步加大调试复杂度。

欠缺标准化 — 若无一个通用平台，语言、日志记录标准和监控手段便可能会激增。

缺少明确责任 — 当推出的服务增多后，运行这些服务的团队数量也会增加。随着时间推移，便难以清晰掌握团队有哪些服务可供使用，以及与谁联系来获得支持。

很多项目最初从单体式结构起步，后来则演变成微服务架构。随着新功能加入单体中，让大量开发人员使用单个代码库可能会变得很麻烦。代码冲突更加频繁，更新某项功能时为不相关功能带来错误的风险也随之上升。发现这些不良趋势时，可能就应考虑向微服务迁移。

以下是我们从内部迁移中总结出的部分最佳实践：

2016 年 1 月，我们共有约 15 个微服务，如今这一数量已超过 1,300 个。我们将 10 万客户迁移到云端，在此过程中构建了一个新平台，转变了我们的文化，并且最终还开发了新工具。我们有更加快乐、自主的团队，以及更加融洽的 DevOps 文化。

微服务可能无法适合所有人。传统的单体式架构或许运作良好，不值得费力去打破它。不过，随着组织发展和应用需求增长，微服务架构可能会物有所值。

许多组织陆续采用具有分布式架构的微服务，因此 Atlassian 开发了 Compass 来帮助更大公司在扩大规模时管理分布式架构的复杂性。它是一个可扩展的开发人员体验平台，可将有关工程产出及团队协作的分散信息整合到一个集中且可搜索的位置。