1.1　微前端应用

微前端是受微服务启发的一种新兴架构。它背后的主要思想是将一个单体代码库分解成多个较小的部分，以便多个相对独立的团队进行分工协作。即使这些团队不在同一个地点，还是能够做到按时交付。

实际上，设计应用程序接口（application program interface，API）并将逻辑封装到微服务中是最简单的部分，我们还有很多其他事情要做。我们需要理解微服务架构的复杂性——它虽然带来涉及不同领域的高度的灵活性和良好的封装，但也增加了系统在可跟踪、自动化以及发现缺陷方面的复杂性。

举例来说，在完成服务的业务逻辑之后，我们需要知道客户端应该如何调用 API。如果它是一个会和其他微服务通信的内部微服务，那么我们还需要确定一个安全模型。接下来，我们要应对微服务的流量变化，比如对峰值流量采取自动扩缩容、缓存等技术。我们还需要知道微服务在什么情况下会出故障，以便优雅地退化，只隐藏用户界面的对应功能，而不会影响微服务的使用方。否则，我们的微服务应该能够在多个可用性区域具有弹性容灾的能力。

使用微服务可以简化业务逻辑，但我们还是要应对各种固有的复杂性，比如网络、持久层、通信协议、安全性等。如果想大幅降低业务逻辑和代码的复杂度，就必须考虑自动化、治理、可跟踪和通信的开销，这对于微前端也是一样的。

和其他架构一样，微前端不一定适用于所有项目。服务器端渲染或 JAMStack 等现有架构仍然是有效的选择。尽管如此，微前端提供了一种大规模构建前端应用的新方式。这种方式不仅从技术上，还从组织上解决了公司过去遇到的在可扩展性方面的一些关键问题。

我经常看到由于项目创建人没有考虑到项目的构建环境和背景，包括公司的组织架构、文化、开发人员的技能、发展历程等，而导致优秀的架构方法没有很好地落地。

关于这个问题，康威定律（Conway's Law）分析得最到位：“任何组织设计的系统架构都不可避免地反映了该组织的沟通结构。”康威定律所描述的困境或许能用逆康威策略来缓解。逆康威策略建议团队的组织架构应该由期望的项目架构来决定，而不是反其道而行之。我坚信我们可以通过掌握不同的架构和了解大量系统的工作方式来降低康威定律的影响，因为这样做会让我们学到足够多的方法来应对来自技术和组织的挑战。

与微服务和要对自身专业领域负责的工程文化相结合的微前端有助于打造敏捷型组织，实现产品快速上市。因为可以对模块进行分治，所以微前端更适合和微服务一起使用，但这不妨碍微前端和其他后端架构组合使用，比如单体（monolith）架构和面向服务的架构（service-oriented architecture，SOA）。