微前端架构：优势，缺点和痛点

这次争论让我想到了过去关于“CSS in JS”的争论。由于我对过去“CSS in JS”的争论一直心怀歉意，这次我会更加的客观去看待这个问题。
我认为就像CSS in JS一样，实际的权衡和差异取决于你的工程和代码组织的限制。实现微前端也有好方法和坏方法，让我们看一下好的，坏的和极其糟糕的微前端。
一. 首先，什么是微前端
“微前端架构”就是构建基于微服务的前端应用架构。
其思想是将前端应用切分为一系列可以单独部署的松耦合的应用，然后将这些应用组装起来创建单个面向用户的应用程序。
微前端的实现各不相同，因为不同的公司的技术方案不同，从服务器端页面嵌入到iframes到Javascript元框架(meta-frameworks)和web components。如果你想彻底弄懂微前端的优势和不同方法，我推荐这篇文篇章。
二. 优势：代码组织的灵活性和一致性
与微服务类似，支持微前端的人都强调可以减少跨团队依赖的代码组织优势。微服务的一些优势包括：

单独的服务单独部署
团队自己进行迭代和更新
围绕业务单元和产品单独组织团队

这些都是实实在在的优点，尤其是对于大型和复杂的项目，但是小的应用程序也能够从独立发布带来一些收益。
在2010年的时候，我开发一个电子商务网站，我一直担心由于一些无关的更改破坏整体的代码。为此我们建立了广泛的测试框架保证不会发生这种情况，现在回想起来对于隔离服务和微前端来说是一个完美的应用场景。
三. 缺点：操作复杂
随着我们从编辑静态文件到复杂的构建系统，移植（transpilation）和大型框架，获得功能良好的前端环境的复杂性已经大大增加。微前端进一步加剧了这种趋势，现在在整个应用程序中进行任何类型的测试可能都需要多个协调的前端，更不用