微服务与单体式架构

单体变得过于庞大时,或可向微服务过渡

Chandler Harris 头像
Chandler Harris

营销策略师与作家


单体式应用是作为单个统一单元来构建的,而微服务架构是规模较小且可独立部署的服务集合。哪一种更适合您?其中的决定因素有很多。

2009 年,Netflix 遭遇发展过程中的烦恼。其现有基础架构无法满足其对视频流媒体服务迅速增长的需求。该公司决定将 IT 基础架构从私有数据中心迁移到公有云,并将其单体式架构替换为微服务架构。而当时的唯一问题在于:“微服务”一词尚不存在,其结构也不为人知。

Netflix 成为首批成功从单体式架构迁移到云端微服务架构的知名公司之一。该公司获得 2015 年 JAX 评审团特别奖,而其中部分功劳要归功于将 DevOps 内部化的这一全新基础架构。如今,Netflix 有一千多个微服务来管理和支持其平台的不同部分,其工程师会频繁部署代码,有时可达一天数千次。

作为先行者的 Netflix 选择了一条如今越来越普及的技术道路:从单体式架构过渡到微服务架构。

什么是单体式架构?


单体式架构是一种传统的软件程序模型,它作为独立自主且不依靠其他应用的统一单元来构建。“单体”一词通常被认为源于冰川这种庞然大物,而这与软件设计中单体式架构的本质也颇为接近。单体式架构是一种单一大型计算网络,它具有一个可将所有业务问题耦合在一起的代码库。要对此类应用进行更改,需要访问代码库并构建和部署服务端接口的更新版本来更新整个堆栈。如此一来,更新便会受限,且较为耗时。

在项目的早期阶段,单体式架构在代码管理、认知开销和部署等方面非常便利。单体式架构中的所有内容均可一次性全部发布。

单体式架构图像
代码构建图标
相关资料

如何构建微服务

三环图标
查看解决方案

使用 Compass 来管理组件

单体式架构的优点


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

单体式架构的优点包括:

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

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

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

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

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

单体式架构的缺点


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

单体式架构的缺点包括:

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

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

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

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

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

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

什么是微服务?


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

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

微服务架构图像

Atlassian 的微服务之旅


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

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

微服务的优点


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

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

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

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

简而言之,微服务的优点包括:

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

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

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

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

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

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

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

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

微服务的缺点


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

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

微服务的缺点可能包括:

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

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

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

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

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

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

单体式与微服务对比图像

关于从单体式架构迁移到微服务架构的 Atlassian 提示


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

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

制定迁移策略

我们专门安排了大量时间来确定迁移客户的顺序。我们知道,许多客户在迁移之后会有不同的配置文件和不同的使用动态,因此我们事先做了相应规划。

使用工具

在进行微服务迁移时,使用正确的工具至关重要。我们没有马上着手迁移客户,而是先投资并创建了迁移工具,因为我们知道迁移是一场马拉松而不是百米冲刺。我们构建的一个最重要工具是 Microscope,这是我们自己用于跟踪所有微服务的内部服务目录。每一名 Atlassian 开发人员都可使用 Microscope 查看公司中任何微服务的所有信息。

我们还在 Microspecore 中构建了名为 ServiceQuest 的工具,以便在生产前自动检测代码检查,包括针对质量、服务设计、隐私、安全性和可靠性的检查。

此外,我们还围绕技术堆栈开发了一个工具。借助内部的一项服务,我们可在特定堆栈上启动新服务,且其优先于日志记录、监控和缓存等事项。最后,我们会尽可能实现自动化,包括迁移过程本身。我们开发了自用的仪表板,以有效地实时查看所有迁移。

管理期望

Atlassian 首席技术官 Sri Viswanath 指出,公司转型需要一位执行发起人来对结果负责并愿意进行必要的权衡取舍。他/她应有能力让组织投资新的工具、系统和流程,以实现永久的改进。

Atlassian 平台负责人 Mike Tria 表示,对于涉及大量人员的大规模基础架构迁移,企业希望了解与投资回报相关的信息。与执行团队、利益相关者、客户、合作伙伴和其他研发团队保持沟通非常重要。确保他们清楚您在做什么,包括预期的效益。另外,一定要庆祝成功。

迎接文化转变

Viswanath ,“在这类大型项目中,文化氛围非常重要。您要确保,每次出现问题,都不会隐瞒不报。”在进行迁移时,这不止是技术上的迁移,也意味着人员和组织的变化。在 2015 年,Atlassian 对运行和部署它的运营团队来说就是“编写代码,然后把它抛过墙去”。到 2017 年底,我们采纳了“谁构建,谁运行”的 DevOps 文化,每一位 Atlassian 开发人员都运行自己的服务。

Tria 说道:“在确保 SRE 团队成功执行项目方面,我花费的时间几乎比项目期间任何其他工作都要多,因为 Vertigo 项目给 Atlassian 带来的最大长期变化就是文化转变。”

平衡速度和信任

Vertigo 项目原本可以更快完成。前四个月后,我们完成了 80% 的迁移。我们本来也能迁移完最后一部分用户,但无法保证他们会拥有我们希望的可靠性和性能。我们坚守了 Atlassian 的核心价值观之一:真诚对待客户。

为保持高可靠性,我们与工程师建立了一套监察与制衡制度,并达到了我们设定的高标准。这是因为,做事尽善尽美、一步到位,从长远来看,您就能节省时间并减少麻烦。

轮到最后 500 名迁移难度最高的客户时,我们使用了 Jira Software 和 Trello 集成,为每一客户分配了专属的 Atlassian 工程师。

总结......


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

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

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

Chandler Harris
Chandler Harris

Legacy 是 Atlassian 的营销策略师和撰稿人。他曾为 40 多种出版物撰稿,涉及技术、科学、商业、金融和教育等主题。


分享这篇文章
下一个主题

推荐阅读

将这些资源加入书签,以了解 DevOps 团队的类型,或获取 Atlassian 关于 DevOps 的持续更新。

Devops 示意图

Compass 社区

克服障碍插图

教程:创建组件

地图插图

免费试用 Compass

注册以获取我们的 DevOps 新闻资讯

Thank you for signing up