从微前端实践总结
目前公司主要是维护一个大的toB平台，整个项目很是庞大，目前是由两个SPA项目组成，使用nginx转发进行两个项目之间跳转，这就有一个体验不统一的问题，跳转菜单时，有些页面是部分刷新，有些页面是整体刷新。另外目前还在进行迭代开发，尽管是分成了两个项目，但是每一个项目也很大，导致build时间很长。
概念由来
同事推荐了一个single-spa的package，真是眼前一亮。它的描述中有一个微前端的概念，微前端首先是由tw的一个工程师提出，Micro Frontends，文中也说了microfront的目的：
In this article we’ll describe a recent trend of breaking up frontend monoliths into many smaller, more manageable pieces, and how this architecture can increase the effectiveness and efficiency of teams working on frontend code.
single-spa
但是single-spa作为jsEntry其实有很多限制：
- 增加一个配置中心：经过webpack打包的静态资源一般都是带有hash串的，每次更新，entry file的文件名是不一样的。所以使用它，你必须增加一套机制来更新app的入口文件名
- 需要hack css的顺序: 有些css的引入会优先在entry file前引入，如果要在single-spa中实现，你需要多写点代码了==
在我的眼中，single-spa是一个引路人，它奠定一个大基础：微前端一定是和技术栈无关的。但是如果要使用它，需要在它的基础上增加很多配置，但是，这些配套的配置很难找到任何指导材料，对于新手来说，很不友好。
qiankun
qiankun是由阿里出品，在single-spa的基础上进行封装的一些框架。相比于single-spa的js entry来说，它采用的是html entry，所以你在原有项目的基础上进行很少的改造，就可以完成介入。
采用html entry之后，它为每个activeApp创建沙盒，来保证不同app的数据的单纯性。但这样带来的问题就是：同一个url上只能对应一个app。我想保证我的portal（基座）项目纯净来保持项目的稳定，对于左菜单右内容的布局来说，想把菜单和内容拆成两个app是不可以的，我不得不放弃一些portal的的稳定性，将菜单放入portal。这是我使用qiankun的最大痛点。
另外还有一些别的微前端框架：
其他问题
1.common resource：每个项目是单独打包，那么无法知道里面的一些公共资源，如何处理common resoures呢？目前我的做法就忽略这个了，没有做这方面的优化
- 联调困难：将项目分离后，开发的时候，就不如之前顺手了。将菜单移出去之后，跳转页面变得困难了==
- 整合项目的复杂度和现有项目有关：如果你的项目不是从脚手架开始的，所有的webpack都是自己配置的，那么你可能在项目build兼容umd上会花费很多时间。
另外，我在想微前端是否可以和微服务进行类比，我可以向它学习一些经验。在spring微服务实战中，里面有介绍微服务的构建要素：
微服务不仅仅是业务逻辑，你需要考虑服务将要运行的环境以及服务将如何扩展并具有弹性
- 合适的大小：如何确保你的微服务具有合适的大小，这样就不会让一个微服务承担太多的职责？
- 位置透明：在一个微服务应用，多个服务实例可以快速启动和关闭，你如何管理服务调用的物理细节
- 有弹性的：你如何保护你的微服务消费者和路由失败的服务应用程序的完整性，并确保你有一种快速失败的方法？
- 可服用的：你如何确保生成的服务的每个新实例都具有与生产中所有的其他服务实例相同的配置和基础代码？
- 可扩展的：你如何受用异步处理和事件最小化服务之间的直接依赖并确保你能优雅的扩展你的微服务？
上面的要素放在微前端的话，可以不用关注这个，k8s完全可以胜任，另外还有两个概念是：服务注册和服务发现，它可以类比成上文提到的single-spa中的配置中心，在go中有现成的envoy可以做这个事情，里面的细节暂不清楚是如何实现的。另外由于前端的代码是最后运行在一个容器中，那么会比微服务会多一个命名隔离的概念，有了css modules你可以解决css的重名问题。
微服务
对比微服务来说，微服务中的重点又是什么呢？
在Spring微服务实战中这样介绍微服务：
微服务是分布的、松散耦合的、单一职责的软件服务
2014 年左史，微服务概念被引入到软件开収社区。它得到了许多试图在技术上和觃模 上挑戓单体应用的大型组织的直接响应。微服务是一个小的，松散耦吅的分布式服务。微服务允许你将一个大型的应用程序分解成易亍管理和职责明确的组件。微服务通迆将大型仒码 分解成小的、定义明确的块，帮劣应对复杂性的传统问题。你需要接受一个关键概念:微服务可仔将应用程序的功能分解和分拆，它们是完全独立的。
看到这我想插一句：之前用ror开发的时候，它就是一个单体应用，所有的代码都在一个项目中，ror现在有微服务相关的指导方案了吗？[TODO]
参考资料：