该不该将单体架构迁移到微服务？( 二 ) _微服务

可见，由于需要一定的资源投入，微服务架构可能并不总是对初创型或中型企业有利。
5.从审查和分析开始迁移正如前文所提到的，从一个单体架构迁移到微服务架构不但繁琐耗时，而且存在着风险。那么，我们怎么能够在迁移之前就认定微服务一定适合本企业呢？《微服务迁移模式》一书的作者--Sam Newman，建议开发人员在动手之前考虑如下三个方面的问题：

您希望达到什么目的？
您考虑过使用微服务的折中方案吗？
您怎么判断迁移的有效性？

下面，我们根据Sam Newman的建议，提出一套分析方法：
6.设定目标

定义迁移对于业务和最终用户的好处，明确企业想通过微服务获得什么。例如：是为了快速开发的整体进程，还是需要减少服务的相互依赖、亦或增加正常运行时间、以及增强可扩展性。
同时，我们需要事先预测系统在完成迁移后的负载和用户数。

7.盘点业务与功能现状企业的应用架构师需要能够找到关联的代码对象，并将它们与系统中的业务功能相匹配。

在现有的单体架构中，可能许多函数由于在其使用域中尚未被明确地定义，或者是业务流程的逻辑较为混乱，因此往往无法被直接迁移或替换。例如：某个组件持续与其他多个组件相关联，那么就很难被拆分为多个普通的微服务。
分析当前的功能，并考虑对其进行优化。例如，通过剔除大量不必要的信息，来优化数据库的查询，或者可以直接更换新的硬件，以及通过开发新的功能，来引入微服务。

8.团队的能力和折中方案

评估团队的DevOps成熟度水平，包括：是否了解DevOps的核心实践，是否具备基本的自动化文化？运营团队是否支持脚本式部署？是否拥有代码即基础设施？是否已有代码评审的标准？团队只有具备了这些成熟的开发和运维实践能力，才能发挥微服务架构的优势。
由于依赖性在服务之间创建了连接，模糊了组件的边界，并导致它们必须组合成单个的模块功能，因此团队只能尝试着从应用的垂直或水平方向进行扩展。
根据项目的特点，仅分离并迁移诸如：电子邮件的发送、通知的推送或电话的呼叫等部分受限的功能。当然，如果您只想从仪表盘系统内剥离出来，从已连接的数据库中收集与分析数据，进而单独形成微服务的话，那么应全面考虑相互之间的关联性。

9.选择可扩展平台为了保证在构建和迁移至微服务时，用户的体验不会受到影响，开发团队应邀请用户一起进行业务需求分析，构建详细的业务逻辑和数据流。有时，您可能需要一个专有的平台来扩展微服务的资源，并能够支持自动化的调整。在此方面，您可以使用由云服务提供商托管的无服务器类型的基础设施，例如：google Cloud、Microsoft Azure和Amazon Web Services等。
10.考虑创建跨职能团队在迁移的过程中，企业需要团结包括开发人员、质量保证（QA）人员、操作运维人员、以及企业所有者等角色，以微服务为驱动，来创建可以从事设计、构建、部署和维护的服务型团队，并尽量简化不必要的审批流程。杰夫·贝索斯曾说：“我们试图创建一支规模不超过两个比萨饼的队伍。”他称之为“双披萨团队规则” 。

文章插图
下面，我将向您介绍从单体架构迁移到微服务架构的一些值得注意的参考经验。
11.定义边界正确的边界往往是有效的微服务架构的基础。相反，如果边界定义错误，则可能导致在新的微服务中，各项功能被频繁更改，特别是那些提供调用的微服务接口，很可能会在随后的集成测试中持续“浮动” 。而且，由于不同微服务出自不同的团队，因此它们会牵扯到团队之间的各种反复协商与较量。
一个典型的域分离的例子源于软件公司Istio 。由于前期定义不足，在迁移到微服务后不久，Istio团队便从用户处得到了各种反馈。他们很快地意识到，微服务并非像他们最初想象的那么实用。其主要原因是：所有控制面的服务都是被一股脑部署和使用的，并且共享着相同的管理和安全域。因此，为了大幅降低Istio的操作复杂性，以更少的精力满足业务需求，并能够更容易地开发出服务产品，他们决定从微服务架构回归至单体架构，并按照相关的技术标准来构建单体架构，识别架构中的业务域边界，并使用公共的API作为接口，来予以实施。
12.选择单体架构中可以被迁移的功能在迁移之前，一个由工程师和作用域专家组成的团队，可以通过了解现有的实现方式、依赖关系、以及内部事件等途径，来确定哪些功能组可以作为微服务，提供最大的产品价值；而哪些剩下的功能，则可以酌情保留在单体架构中。