翻译|陈军审稿人|孙书娟目前业界最常见的软件范式有：Monolith和微服务架构。两者的逻辑结构如下图所示。一般来说：微服务架构是关于将应用程序表示为微小的、松散耦合的服务的集合。由于将整体的复杂性转移到服务的协调层面，每个服务代表一个业务功能，更容易定位相关代码。单体架构就是把几个离散的功能组合成一个单元，作为一个整体进行测试、部署和扩展。由于所有组件都是相互依赖的，它们通常不能独立运行。这意味着一个模块中的错误可能会减慢甚至破坏整个应用程序。1.微服务架构的优势我们长期使用和熟悉单体架构。接下来主要讨论微服务架构的优点：易于扩展，应用组件相互独立，边界清晰，可以通过HTTP通信实现，可以使用不同的编程语言和数据存储，开发过程可以分成多个团队可独立部署易于更新和维护代码库较小2.微服务架构的缺点难以监控且服务更复杂部署服务它们之间的通信需要额外的安全加固，性能会有所降低。鉴于分布式系统的远程调用速度慢，往往存在较高的编程难度和失败的风险，增加了操作的复杂度。3、何时选择微服务2001年，面对各种应用请求的增加、编码问题突出、开发滞后、服务间相互依赖等问题，亚马逊逐渐意识到需要从头开始重建系统，于是将其单体应用进行了分解分成小型独立的、独立的特定于服务的应用程序，开创了微服务架构。该架构实现了一种模式，其中一个服务接受订单，另一个服务生成推荐购买列表，第三个服务提供简单的身份验证服务等。正如MartinFowler早在2015年就如何构建实用软件给出的建议：“几乎所有成功的微服务案例都是从拆分一个巨大的单体架构开始的。”选择微服务的趋势不一定是正确的。一般我们认为以下应用和代码设计需求更适合企业选择转微服务：系统负载大，需要与不同的支付系统进行交互。用户需求不断增长，规模不断扩大，现有应用系统经常中断。整体式应用程序变得不那么灵活并且无法升级。为了在竞争激烈的商业环境中取得成功，需要加快应用程序开发和发布时间，并且可以在以后进行功能更新和升级。需要实施人工智能等高级商业智能解决方案，以获得更深入、更具竞争力的商业数据、报告和分析。当前的基础架构无法提供处理大数据处理负载所需的水平可扩展性。上图是亚马逊在2008年完成的被称为“死星”的微服务基础设施。4.向微服务迁移面临的挑战。存在各种技术和组织挑战，因此我们有必要了解随之而来的各种风险：麻烦和耗时。由于从单体应用到微服务的整体迁移非常耗时耗力，企业往往会选择“小步走”的方式一步步迁移。如果在迁移过程中需要引入新的服务特性，开发团队将不得不投入更多的精力。更高的成本。无论是从开发和编码的角度，还是从支持、运营和变更的角度来看，迁移到微服务的成本都很高。企业需要在构建基础架构、开发文档和重构应用程序方面投入大量资金。由于微服务是分布式系统，开发团队需要选择并实现基于消息传递或RPC的进程间通信机制。移动代码库。为了成功地将数据从现有的单体架构中提取到与微服务匹配的数据库和代码库中，我们可能需要重构其实现过程并通过完整的测试覆盖，以避免引入新的错误。组织变革。为了实现迁移，企业需要将现有的大项目团队拆分成能够独立工作的小团队。同时，企业仍然需要保持一致的组织结构。团队对他们的服务负责。迁移完成后，每个团队都会有自己的代码库。一旦服务出现问题，他们就不能再怨天尤人，而需要从自己身上找原因，??自己解决，负责到底。此外，无需系统停机即可迁移并保证用户可以持续访问应用程序。这本身就存在一定的风险。可见，由于需要资源投入，微服务架构不一定总是对初创企业或中型企业有利。5.从审查和分析开始迁移如前所述，从单体架构迁移到微服务架构是繁琐、耗时且有风险的。那么，我们如何在迁移前确定微服务一定适合这个企业呢？《微服务迁移模式》一书的作者——SamNewman，建议开发者在做之前考虑以下三个方面：你想要实现什么？您是否考虑过使用微服务的权衡？如何判断迁移的有效性？下面，我们根据SamNewman的建议提出一套分析方法：6.设定目标来定义迁移对业务和最终用户的好处，明确企业希望通过微服务实现什么。例如：对于快速开发的整体流程，或者需要降低服务的相互依赖性，或者增加正常运行时间，增强可扩展性。同时，我们需要预测迁移后系统的负载和用户数量。7.业务和功能状态盘点企业应用架构师需要能够找到关联的代码对象，并将其与系统中的业务功能相匹配。在现有的单体架构中，很多功能可能因为没有明确定义其使用领域，或者业务流程逻辑混乱，无法直接迁移或替换。例如：一个组件与多个其他组件持续关联，因此很难拆分成多个公共微服务。分析当前功能并考虑对其进行优化。比如通过剔除大量不必要的信息来优化数据库查询，或者直接更换新硬件，通过开发新功能引入微服务等。8.团队的能力和妥协评估团队的DevOps成熟度水平，包括：是否了解DevOps的核心实践，是否具备基本的自动化文化？运营团队是否支持脚本化部署？你有代码即基础设施吗？是否已经有代码审查的标准？团队只有具备了这些成熟的开发和运维实践能力，才能发挥微服务架构的优势。因为依赖关系在服务之间创建了连接，模糊了组件的边界，并导致它们必须组合成一个单一的模块功能，所以团队只能尝试垂直或水平扩展应用程序。根据项目特点，仅对部分受限功能如：邮件发送、通知推送或电话呼叫进行分离迁移。当然，如果只是想脱离dashboard系统，从连接的数据库中收集和分析数据，然后单独形成微服务，那么就要充分考虑相互之间的关系。9、选择可扩展的平台为保证在构建和迁移到微服务时不影响用户体验，开发团队应邀请用户分析业务需求，构建详细的业务逻辑和数据流。有时，您可能需要一个专有平台来扩展微服务的资源并能够支持自动调整。在这方面，您可以使用由云服务提供商托管的无服务器类型的基础设施，例如：GoogleCloud、MicrosoftAzure和AmazonWebServices等。10.考虑创建跨职能团队在迁移过程中，企业需要联合包括开发人员、质量保证（QA）人员、运维人员和业务负责人在内的角色，在微服务的驱动下，创建、构建、部署和维护以服务为导向的团队，并尽量减少不必要的审批流程。JeffBezos曾经说过：“我们试图创建一个不超过两个披萨的团队。’”他称之为“双披萨团队规则”。下面，我将向您介绍一些从单体架构迁移到微服务架构的著名参考资料。11.DefineBoundaries正确的边界往往是有效的微服务架构的基础。相反，如果边界定义不当，可能会导致新的微服务中功能频繁变化，尤其是那些提供调用的微服务接口，很可能在后续的集成测试中继续“漂浮”。而且，由于不同微服务来自不同的团队，会涉及团队之间的各种反复协商和较量，领域分离的一个典型例子来自软件公司Istio，由于早期定义不充分，在迁移到微服务后不久，Istio团队得到了来自各种反馈用户。他们很快意识到微服务并不像他们最初想象的那么实用。主要原因是：所有控制平面服务都由一个大脑部署和使用，并共享相同的管理和安全域。因此，为了大大减少Istio的运维复杂度，更轻松的满足业务需求，更轻松的开发服务产品巧合的是，他们决定从微服务架构开始回归单体架构，按照相关技术标准构建单体架构，在架构中明确业务领域边界，并使用公共API作为接口来实现。12.选择单体架构中可以迁移的功能在迁移之前，工程师和范围专家团队可以通过了解现有的实现方法、依赖关系、和内部事件；其余功能可酌情保留在单一架构中。13、微服务的独立数据存储每个微服务都需要有一个数据仓库，这在一定程度上增加了分离数据的管理。困难。由于单个存储系统很容易因失去同步而变得不一致，因此您需要使用可以执行主数据管理(MDM)的工具。例如，它可以为每个用户ID查询数据库，及时发现是否有相同的ID。据此，即使某项服务停止工作，也可以保证用户数据的安全。当然，最理想的情况是同时将数据存储在微服务和单表中。14.保留微服务的代码通常，与其在性能良好的微服务中添加或重写一段代码，不如为新的或更改的代码创建或部署新的微服务。据此，我们不仅可以简化了新代码的测试，并且可以减少微服务中现有服务出错的可能性。15.单独构建微服务通过为每个微服务单独构建，我们可以使用适当的修订级别获取组件文件。16.在容器中部署微服务为了尽可能简化，我们最好使用相同的工具在容器中部署微服务。例如，Docker是广泛推荐的容器标准。17.典型的成功迁移案例Netflix（Netflix）为了能够24/7全天候运营，Netflix需要一种架构来优化交付速度并扩展到下一个数据量。因此，Netflix决定在垂直扩展时摆脱数据中心关系型数据库带来的单点故障，采用NoSQL数据库对数据模型进行非规范化。同时，公司采用了云服务提供的高可靠、可横向扩展的分布式系统，并通过选择AWS作为云服务提供商，获得了大规模、广泛的服务和功能。此外，微服务架构还允许Netflix将系统划分为独立的服务，包括：存储所有观看节目的服务、负责每月信用卡支付的服务以及分析观看历史以提供类似电影节目的服务.公司的整个迁移过程耗时七年。Netflix的微服务基础设施逻辑图Wix.com由于Wix.com的应用程序是相互连接的，一旦系统的某个部分出现问题，就会导致整个系统崩溃。对此，Wix.com开创了一种全新的集成端到端测试模式，采用JSON/RPC协议，在SpringMVC的基础上构建了一套微服务框架。通过迁移，他们解决了处理微服务之间的通信、故障和调试等技术债务。CloudElementsCloudElements使用Minikube和Docker等工具管理本地和远程运行的服务。由于所有的微服务都在Node.js中，他们使用Ava等基于npm的单元测试包来实现代码测试的全覆盖，以应对业务的指数级增长，并根据新的需求不断迭代他们的微服务。服务。百思买（BestBuy）过去，相互依赖的架构导致百思买在业务部署上遇到困难。长时间的宕机给其线上业务的维护带来了不小的挑战。开发团队往往需要将新功能一个一个打包，然后累积发布。如今，他们通过Chef和Jenkins等工具实现持续集成和部署，并将数据库迁移到Riak（分布式NoSQL键值数据存储）。18.总结综上所述，我们是否应该跟上软件架构的趋势，抛弃单体架构，投入微服务的怀抱，目前还没有绝对的定论。我的观点是：如果目标项目既没有高负载，也没有频繁与外部服务交互，那么我们可以选择或维护单体架构；而如果系统必须在大量负载和服务请求下工作，那么微服务架构将是更好的选择。再来看看公司的组织架构。如果你的公司只有一个开发团队，那么建议你专注于单体架构的构建和维护；但如果你有几个IT团队可以同时开发同一个产品，微服务会更合适。客观地说，微服务架构有利也有弊，它只是构建软件的另一种方式。您是否应该选择完全取决于您的应用程序的业务需求。当然，你也可以从一个简单的单体架构开始，随着服务需求的增长逐渐隔离应用组件并迁移到微服务。这可能是一种更安全的应用程序做法。原文链接：https://dzone.com/articles/Monolith-vs-microservices-architecture-split-or-no译者简介JulianChen，社区编辑，拥有十余年IT项目实施经验，擅长实施管控内外部资源和风险，重点传播网络与信息安全知识和经验；持续以博文、专题、翻译等形式分享前沿技术和新知识；经常开展信息安全线上线下培训和教学。
