@levinzhang
2022-10-01T05:22:22.000000Z
字数 4475
阅读 275
企业在从创业状态进入成熟期时，会面临架构方面的诸多挑战。为了适应可扩展性，在后端我们可以从单体转为微服务，而在前端，我们可以采用微前端模式，本文介绍了企业在过渡期采用微前端所带来的收益以及诸多技术方面的考量因素。
本文最初发表于ITNEXT的博客站点，经原作者[Manu Ustenko授权由InfoQ中文站翻译分享。
在本文中，我将会讨论从创业公司到成熟公司过渡时期的可扩展性问题，分享我的想法，并介绍在我工作的组织中所使用的技术。
有很多文章都讨论多可扩展性这个话题，但是我想要澄清在本文中，可扩展性的含义：
可扩展性指的是在系统生命周期的每个阶段，前端系统都能以更快、更可靠和更简单的方式向终端用户交付价值的能力。
一个可扩展的应用应该具备很多的原则，但是我想要强调其中最重要的一条：关注点分离与架构设计。
在本文中，我将会基于团队拓扑概念进行阐述，并且会按照功能将团队分为四个组，分别是业务导向（stream-aligned）团队、赋能（enablement）团队、复杂子系统（complicated subsystem）团队和平台（platform）团队。
我们正生活在一个创业公司的时代中。每天都有新的创业公司开业或关闭，企业家们都在寻找新的机会，为我们的生活带来新的商业模式。在这个过程中，我们不断看到个人和公司的成长与失败。
从技术角度来看，在公司生命周期的这个阶段，公司中的技术规模比较小，易于维护，易于为业务带来新的价值。在这个阶段犯错并不致命，可以很容易地解决。当然，这并不意味着最初的架构不重要，企业需要非常优秀的专家，他们可以在公司的早期阶段做出正确的架构决策。在这个阶段，一个或两个开发小组（每个小组有5到10个成员）就足够了。我认为如果在这个阶段拥有更多的团队将是组织方面的错误。
在公司的这个时代，从前端的角度来看，最佳方式使用较小的单体应用。它有很多的好处：
我们不会过多地讨论IT巨头和成熟的公司。我们只需要知道，成熟的公司已经有了良好的业务、工作流程、行业基础并且会有多个团队专注其功能。
在这个阶段，关键要素之一就是将功能性的任务分派给专门的团队，每个团队专注自己的功能，不允许任何团队涵盖多个功能。
随着时间的推移，创业公司会达到一个沸点，前端应用开始变得不再灵活，无法与业务保持相同的速度。
在试图交付新的功能以满足业务需要时，每个交付周期都会延迟。技术团队对业务的承诺经常落空，他们还没有认识到环境已经发生了变化。团队依然认为他们能够如期交付某个新特性，但是却一次又一次地失败。
组织可以通过增加团队或工程师的数量来满足重要的需求。但令人遗憾的是，在很多情况下，将更多的人塞入到技术团队中并不会带来任何的价值。现在，应该改变流程了。
系统难以进行扩展的症状包括：
在过渡期间，如果出现技术错误，其代价是非常高昂的。在这个阶段，创业阶段的错误会逐渐显露出来。
为了让业务继续保持增长，组织中的技术领导层应该调整目前的状态。流行的方案就是将单体架构迁移至微服务（后端技术）或微前端（前端技术）架构。
由于本文讨论的是前端技术，所以我会继续讨论微前端，而不是微服务。同时，我也不会讨论微前端架构是好是坏以及哪种微前端方式更好的问题，因为这方面已经有很多的文章和讨论了。
相反，我会从可扩展性的角度来考虑微前端架构，以及它是如何解除企业在转向多团队模型时所面临的障碍的。
微前端是一种架构风格（模式），在这种风格中，独立交付的前端应用会被组合成一个更大的整体（microfrontends.com）。
这是一种会影响组织的技术，会让团队之间解耦，避免出现过多的集中化，最重要的是，这会给团队授权，让他们针对自己的功能进行决策，不必依赖其他的团队。
一旦某个组织出现了我们上文所述的难以扩展的症状，工程师就可以决定将系统从单体架构转换成微前端架构。与此同时，它会给企业带来一系列的收益。
微前端架构允许团队将单体应用的代码库分割成更小块的代码。每个独立微前端的源码规模将小得多，并聚焦于应用中一小部分的功能。应用中的哪一部分要解耦成微前端，这应该由工程团队决定。它可以是很大的内容（如页面）也可以是很小的内容（如元素）。借助新的代码组织形式，新开发人员花更少的时间就能掌握代码库，并在短时间内就开始对代码做出贡献。
微前端的代码库应该是隔离的，这有助于业务导向团队选择自己的工作策略和流程。每个团队对应用的一个垂直切片拥有全部的所有权，并且可以在其领域内进行专业化。他们不用担心团队之间的干扰，这减少了团队之间的协调需求。微前端能够让应用按照团队的结构进行组织，这遵循了康威定律。
设计系统的架构受制于产生这些设计的组织的沟通结构
- Melvin E. Conway
具体样例：
如果某个团队想在单体架构中尝试新的技术（新的状态管理器、测试库等），这个决定需要在所有从事该应用的团队间取得一致。这很费时间，而且最终可能难以被一些团队接受。如果团队是独立的，该团队的工程师就可以决定要使用什么技术。这个决定完全不涉及其他的团队。
与微服务的方式相同，微前端要对它的部署负责。它让业务导向团队能够独立发布应用的某一部分。此时不用重新部署整个应用，每个团队都可以只部署其中的小部分功能。这能够让团队在发布的时候，不需要与其他团队协调，也不需要适应全公司的发布周期。如果最后的部署出现问题，能够很容易地回滚而不影响其他团队的工作。将代码库分割成小块，使得微前端的部署需要更短的时间。
采用微前端的原因之一就是实现垂直领域的所有权拆分。从整个公司掌握所有权的单体架构，转变成多个团队掌握所有权的微服务，这有助于公司在不同的团队中扩大开发规模，促进后端所有权的拆分。每个业务导向团队都拥有一个垂直方向的组件，他们从头到尾负责该组件。
与大型应用相比，少量的代码更易于测试覆盖。这会促成整个系统中更好的测试覆盖率，因为所有小部分的代码都会被测试覆盖到。
微前端的优势之一就是不依赖于所选择的技术和框架。它更容易找到专门的团队来完成微前端的工作，允许使用其他的技术和框架取代不适用的技术和框架，也能够以较小的技术风险测试新技术。
接下来，我将介绍微前端架构应该遵循的最重要的原则，以保持系统的可扩展性。要实现这一点，我们要引入两个术语：
不管技术团队具体使用哪种微前端的方式，为了保持系统的可扩展性，遵循下面这些强制要求是非常重要的。
子微前端和编排器之间的强制要求：
子微前端之间的强制要求
决定采纳微前端架构并不是过渡旅程的结束。这将是一个痛苦和危险的过程，但同样也是一个有趣的认知经历。许多陷阱将等待工程团队去解决。
其中一个问题是整个微前端架构的维护问题。随着时间的推移，系统可能会有几十甚至几百个微前端，而工程团队将面临新的挑战：如何维护这些微前端。
如何引入新的微前端应用将是工程团队在迁移到微前端架构后遇到的第一个问题。如何在不增加复杂性的情况下搭建一个新的微前端脚手架？由哪个团队负责创建新的微前端？微前端应该遵循哪些标准？
这些相关的问题必须由工程团队解决，以保持系统的可扩展性和易维护性。否则，系统在很短的时间内就会变得非常混乱。
我们预期得到的解决方案是，每个新的微前端都能快速创建，并且有非常相似的设置，以保持所有微前端之间的一致性。我想到了“传送带（conveyor）”这个词。
我们有多种方法可以达成该目的。我想和大家分享一个如何实现该目标的想法，那就是使用一个可以在几分钟内基于模板创建新微前端的工具。这可以是现成的解决方案，如cookiecutter或其他类似工具。
创建新的微前端只是万里长征第一步。随着时间的推移，将会有许多微前端需要与基本模板进行同步。这可能也是我们需要模板的原因：解决漏洞、更新配置、更新其他软件包的版本等。
令人遗憾的是，cookiecutter无法将现有的项目与模板同步。为了解决这个问题，在我的公司中，我们开发了自己的解决方案，它可以为新创建或已有的微前端提供一个脚手架。
在编写概念验证（Prove of Concept）项目的过程中，我创建了mucli项目，它基于我们组织中遵循的类似原则。该项目会在Github上获取仓库，在仓库中寻找模板，并创建新项目或同步现有的项目。它提供了如下开箱即用的功能：
欢迎了解mucli项目并为其贡献内容。我将在接下来的文章中深入探讨它的实现细节。
在这篇文章中，我分享了我们从创业公司转变为成熟公司期间的想法和决定。如果你对这些话题感兴趣的话，可以通过GitHub或Twitter与我联系。