之前在另一家公司实习的时候就被微服务架构等一系列词汇搞得晕乎乎的，好在最后也没涉及这方面的事情，也就不了了之了。
最近又刷到了这方面的东西，正好现在公司里有一些相关的事情（在架构上），也正好做一个学习了解，捋一捋微服务（micro-service）、微前端（micro-frontend） 还有一个更摸不着头脑的 “无服务”（serverless） 是什么东西。
当然，因为最近做的一直是前端开发这方面，我的重心自然会放在微前端上，但由于这是个历史发展的概念，只有理解了微服务的发展历史才能更好地理解为什么需要、如何利用微前端架构进行开发。因此我不会细究微服务的部署，但会尝试微前端的部署过程与实例。
软件架构分为许多类别，如单体架构、微服务架构、分布式架构等，它们虽有出现的先后顺序之别，但严格意义上并没有先进与否的区别，只是适用于不同的应用场景项目规模。
比如你一个小的不能再小的应用，非要上分布式或者微服务，那可能就是脱了裤子放屁，可能RPC开销、管理成本、MapReduce开销等等都会超过你任务本身的开销，因此还是应该按需选择最合适的方案。
要理解微前端本身，我们首先要从软件架构的发展讲起，理解为什么需要微前端架构。
单体架构（monolithic software）是一种将所有功能和逻辑写在一个项目（或部署在一个项目/容器）中的写法，一个实例中集成了一个系统的所有功能，并通过负载均衡软件/设备实现多实例调用。
如我们熟知的MVC、MVVM架构严格意义上都属于单体架构，它们虽然在业务逻辑（如视图层、View Model和逻辑层）上做了区分，但本质上仍是单体应用。
区别一个单体应用最好用的方法就是：你对其中某一个功能进行改动，会不会需要重新编译整个项目？需不需要担心耦合造成的蝴蝶效应？ 如果会，那就是单体应用。
最开始的单体架构是所有功能都耦合在一起，甚至前后端不分离，但随着项目体量的不断扩大，单体模式的弊端逐渐显露出来，如：扩展性差、无法实现复杂业务、技术升级困难等。
为了解决上述问题，人们给单体架构打了一些“补丁”，对代码进行拆分来提高维护性：
