微服务迁移前，来听听这6个思考和经验

小数近期为你们推送了很多微服务方面的文章，以前的一份微服务调研报告《[微服务2017年度报告出炉：4大客户画像，15%传统企业已领跑]受到普遍关注。今天推送的这篇技术文章，与您再来深刻探讨下企业为何要寻求微服务，会遇到哪些问题，作好哪些准备。

今天，对软件的需求变化比以往任什么时候候都快。这就要求有一个合适的架构来实现灵活的变动。然而，考虑到Web应用的角度，灵活性每每受到阻碍。随着时间的推移，各类意想不到的依赖关系会使架构看起来像一个大泥球（Big Ball of Mud，BBoM)。

相似BBoM的庞大单体架构显示出的复杂性急剧增长。这须要各个团队之间的协调努力，才不会致使生产力下降。做为对策，企业引入了Scrum敏捷方法来优化他们的软件工程流程。可是，常常缺少技术自主权。

敏捷性和微服务

在敏捷软件开发中，一个理想的架构足够灵活，能够处理快速调整的需求。遵循敏捷宣言的原则，最好的架构以功能需求驱动的方式出现。但架构也须要前期设计的努力，以实现预期的灵活性。因为需求的不肯定性，严格的瀑布式的前期大型设计（Big Design Upfront ，BDUF)被忽略了。BDUF不适合大量连贯工做量的敏捷思想，也称为the batch size。

微服务方法限制了batch size，由于每个微服务只涵盖整个应用的一部分。全部部分共同涵盖不一样的业务功能，例如在电商应用中显示产品的详细信息。重要的一点是，单一业务能力的责任转移到一个须要跨职能一致和须要DevOps文化的团队。

所以，微服务是一个模块化的概念，能够解释技术层面和组织层面。这个想法是围绕清晰分离的业务能力建模一个架构，每一个业务能力都是做为一个微服务实现的。经过实施本身的架构与系统的其余部分分离，容许创建大规模的软件增量与小型和独立的团队。微服务最适宜的企业是，旨在缩短业务上线时间，但没法应对当前架构和组织结构快速变化需求的那些企业。

向微服务迁移有许多挑战。如下提供了从BBoM引入微服务的几点指南。

微服务迁移的六大影响因素

向微服务的迁移能够彻底脱离，也依赖于单体（因素1）。关键的决定是，目标架构的微服务是否包含本身的前端（frontend）（因素2）。在这个阶段，技术和组织方面之间的相互做用已经变得明确。当涉及从巨石中分离出第一个微服务时，应该确保底层的新模型不会被旧的破坏（因素3）。运维中的迁移应该考虑风险，并采起适当的措施（因素4）。经过自动化过程来支持（因素5）。把适当的工做放在优先位置。所需的透明度经过敏捷的组织文化来创建。将敏捷转换与微服务迁移结合起来会带来额外的挑战（因素6）。

1改变

人们常常认为，彻底重写应用程序是充满风险的。可是这个应用程序的发布并非以一个Big Bang的方式来完成的。相反，能够选择渐进的方法。可是，巨石应用和微服务一块儿构成应用程序的“微服务 – 单体 - 混合”架构每每是不可避免的。特别是若是有竞争的压力，新的特性必须不断传递给客户，那么混合是惟一的解决方案。迁移是一个长期的过程，能够持续2年以上。

为了缩短应用程序处于混合状态的时间，建议将迁移视为变化的机会。在这种状况下，改变意味着实施新的要求，并且接受现有功能的遗漏。一方面，考虑迁移的应用程序是旧的应用程序的准确副本，减小迁移工做是明智的。另外一方面，提供不适用于旧技术堆栈的新功能加强利益相关方的信任。这种迁移能够视为进步而并不是停滞。

2系统分解

有两个必须考虑的决定。首先，是否经过使用现有的代码库或者彻底重写功能来提取微服务。其次，定义目标架构，而且必须作出决定，微服务是自带前端，仍是多个微服务集成在一个UI单体中。

当使用现有的代码库时，该代码库的副本就是跳板。那么给定的部分已经表现出高度的自主性。并且，当项目范围局限于较少人数开发应用时，这种方法可能会取得成功。当挑战是将多个团队分离时，建议将微服务定义为本身的前端。

图1：2层微服务 VS 全堆栈微服务

这须要进一步讨论如何解释微服务的层次。关于三层架构，能够区分两种微服务类型。一方面是只包含数据和应用程序层的微服务（图1）。另外一方面还有从数据层到表现层的微服务。

图2：UI-monolith 与 UI-fragments

当使用“2层微服务”时，在创建前端的这种多微服务时创建了一个UI单体。这带来了将微服务整合到同一个前端的耦合团队的风险。相比之下，提供本身的前端部分的“全栈微服务”（例如UI碎片）则为团队提供了更高程度的自主权（图2）。

3模型边界保护

做为一个起点，建议从中等复杂度的单个上下文开始。这样作的时候，保护即将实现这个上下文的微服务底层模型很重要。所以，应该规定一条规则，即禁止经过数据层访问（如JDBC或直接API调用）从总体数据访问数据。相反，数据应该从后台异步传输到后台的微服务，同时还要在新旧模式之间进行转换。这能够看做两个数据存储的同步，并符合构建防腐层（ACL）的思想，这是一个域驱动设计（DDD）的概念。在这种状况下，ACL能够做为微服务和巨石的模型完整性保护器（图3）。

图3：ACL做为微服务和单体之间的边界

4风险监测

任何迁移都有风险。特别是在进行彻底重写时，若是新应用程序与现有应用程序相比获得相同的结果，则应使用与业务相关的度量标准（如营业额）进行衡量。而后，经过逐渐将新应用交付给愈来愈多的客户，控制经济风险。在这一点上，应该考虑诸如Canary Releasing的部署策略。

另外，建议在生产环境中测试微服务，而后再将其推广给客户。这能够经过向微服务提供请求并彻底观察他们的行为Shadow Traffic来实现。性能问题能够在不影响应用程序的状况下展开，由于各自的响应被省略。这种作法是由两位专家和文献描述的。

其余措施也能够支持下降云服务迁移过程当中的风险。使用诸如特性切换之类的机制在旧的和新的实现之间切换。它们提供了灵活性，仅经过更改配置来控制这一点，而无需从新部署整个应用程序。

5自动化和测试

为了减小TTM（上市时间），做为微服务的部署流水线，建议将价值流建模和自动化。在这里，要考虑从代码提交到部署构建的每一步。这确保部署能够常常进行。此外，这从一开始就支持高度的测试覆盖，由于测试也是该流水线的一部分。

在考虑自动化测试时，专家会参考所谓的自动化测试金字塔。测试金字塔由三个测试层组成：单元，服务和UI测试。每层测试的数量减小，致使金字塔形状--许多单元测试和少许UI测试。为了确保多个微服务如预期的那样相互整合，依靠UI测试是合理的。但UI测试对于开发和维护来讲是脆弱和昂贵的。这就是为何在没有UI的状况下单独进行测试很是重要：使用模拟对象自主地测试微服务。借助模拟对象，能够模拟与其余微服务或巨石应用的交互。相应的测试被称为，自动测试金字塔内的服务级别测试。

6敏捷转型

引入敏捷方法并当即迁移到微服务是巨大的变化。所以，建议将其分红几个步骤，并寻求逐渐改变。不然动机和定向障碍的风险过高。经过引入Scrum这样的敏捷方法，理想的微服务出现，是随着时间的推移争取团队的自主性。

尽管Scrum主要是在一个跨职能和以产品为中心的团队中解决软件开发过程，大规模的组织也须要采用。Scrum没有提供解决多个敏捷团队协调的解决方案。还有一些坚决的观点认为，对于大型项目来讲，应该避免使用灵活的方法来分割产品。随着时间的推移，出现了不一样的Scrum和敏捷方法扩展方法。例如，LeSS（大规模Scrum），Nexus和SAFe（缩放敏捷框架）是根据其市场份额为大型组织提供敏捷性的相关方法。

在更大的组织环境中创建敏捷方法时，建议先从一个团队开始，而后再增长愈来愈多的团队。一样在LeSS中，这被描述为耗时，但倒是以功能为中心的团队，同时打破功能孤岛的安全方式。

透明度

此外，建议记录产生的非功能性工做，例如在积压工做中实施ACL，并合理安排其余要求。在SAFe中，引入了能够表明上述技术和机制的实施以及迁移工做的推进者的故事。它们确保了透明度，展示了业务与IT之间潜在的相互依赖关系。所以，应根据2位专家的建议，与企业和技术负责人进行优先排序。

图4：敏捷和微服务之路

总结

微服务包含组织层面和技术方面。这就是为何引入微服务涉及两种状况下的措施。若是没有单体考虑，微服务的好处是脆弱的。从纯粹的技术角度来看，微服务可使用瀑布式软件工程方法来实现。可是，为了充分发挥每一个微服务的自主性，它们被嵌入到敏捷文化中。

特别是，拥有多个团队的组织能够从微服务的非技术方面获益。从数据层向前端分解一个系统，将团队分离开来。所以，若是多个团队使用一个前端开发应用程序，那么团队边界在架构中反映最好。这些团队能够自主地加速应用程序的部分。在单体应用程序和分层的团队中，这是更困难的。在这里，复杂的依赖须要协调跨越团队边界的活动。所以TTM降低。

因为敏捷团队由开发人员和非技术人员组成，所以IT和业务须要携手合做。微服务的出现是因为敏捷团队争取自主权。当团队决定转向微服务时，迁移自己没有任何价值，能够向客户交付新功能。尽管如此，微服务迁移工做仍须要优先考虑。这须要透明度。只有不断提升透明度，敏捷性和微服务才能彼此加速。不然，长期不会下降TTM的风险很高。

为了不在引入微服务时构建将来的传统软件，创建敏捷思惟和不断从新思考解决方案很重要。

原文连接：

6 Things to Consider for Microservice Migration

https://www.inovex.de/blog/mi...