微服务（Micro Services）架构是个很有趣的概念，它的主要作用是将功能分解到离散的各个服务当中，从而降低系统的耦合性，并提供更加灵活的服务支持。
概念：把一个大型的单个应用程序和服务拆分为数个甚至数十个的支持微服务，它可扩展单个组件而不是整个的应用程序堆栈，从而满足服务等级协议。
微服务应用往往由多个粒度较小，版本独立，有明确边界并可扩展的服务构成，各个服务之间通过定义好的标准协议相互通信。在构建微服务架构时，模块化(Modularity)和分而治之(Divide & Conquer)是基本的思路。
微服务与单一服务对比：
单一服务抽象模型：
�微服务抽象模型：
抽象模型对比：
从系统衍化的角度讲，在系统早期流量较少时，只需一个应用将所有功能都部署在一起，以减少部署节点和成本。随着流量逐步增大，我们过渡为了包含多个相互隔离应用的垂直应用架构；即是将不同职能的模块分成不同的服务，也逐步开始了微服务化的步伐。接下来，随着垂直应用越来越多，应用之间交互不可避免，将核心业务抽取出来，作为独立的服务，逐渐形成稳定的服务中台。
单一服务应用模型：
�微服务应用模型：
当我们讨论某种技术，一定要关注两点：引入新技术付出的成本和带来的收益
微服务架构下，每个服务的复杂度大幅下降，从而维护成本也大幅降低。对于团队来说，新人也可以更快地上手项目，贡献代码。交接项目也变得更加容易。
单一服务架构下，随着时间的推移，项目的复杂度必然越来越高，相关人员也会越来越多，从而代码的合并频率会逐渐下降，权限越来越难以分配，需要越来越重的测试，部署也越来越复杂，频率越来越低。
然而微服务也会带来很多问题，例如如果设计不合理，整体的复杂度会提高。写代码的时候需要考虑调用失败的情况，需要考虑分布式的事务（当然很多时候是设计不合理导致的），从而对人提出了更高的要求。总之，微服务带来了很多优势，同时也带来了很多挑战，我们需要认真的审视自己，这些优势对当下的我们是否是优势，这些挑战对当下的我们是否能hold住。
微前端�概念：微前端（Micro Frontends）概念在2016年从服务端扩展到前端层面，意在同时构建多个完全自治和松耦合的�应用模块，其中每个App模块只需要负责特定的UI元素和功能。
��很多资料在讨论微服务时特别喜欢引入康威定律中的一句话�：
Organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations. - Melvin Conway(1967)；
翻译1：� 组织机构在设计系统时往往�拘泥于自身的组织架构。
翻译2； 设计系统的组织，其产生的设计和架构等价于组织间的沟通结构。
通俗的说法就是：组织形式等同系统设计。
微服务与微前端不仅仅是技术架构的变化，还包含了组织方式、沟通方式的变化。
微前端的价值：
- 多个团队协作可以减少相互影响，可以独立开发和部署。
- 测试和回归问题更方便，修正功能点可以不必再触碰整个应用。
- 每个团队在bugfix和后期维护�中只需要关注自己所开发的特定区域。
总结起来是八个字：快速发布，�多团并行。
微前端的弊端：
- 开发环境的集成复杂，需要考虑隔离js，避免css冲突，按需加载等问题。
- �第三方模块的引入和团队之间共享资源的关系会很复杂。
- 多个App模块的初始loading时间可能会增加（可能需要服务端渲染配合减少首屏加载时间）。
- 多个App模块的数据同步和数据通信问题。
总结起来是两个字：规范
从目前项目来看，普通单页面应用可以满足当前需求，但是如果未来�在蘑菇智行app或者我们真正打开市场的app上扩展出很多应用和生态，类似小程序或者支付宝内置功能应用模块，那么微前端架构就变得很有必要了。
实施前端微服务化的多种方式：
https://zhuanlan.zhihu.com/p/39102712
目前已存的实现：
依据以上定义，如果打造一个属于我们自己的微前端方案�，我们应当考虑哪些方面？
- 如何合理拆分现有前端部分？
- 公共模块和资源的引入规范。
- 各个团队独立部署和发布的流程规范。
- 微前端模板�实现。
- 各个服务之间的组合方式 构建时？运行时？。
- 各个服务之间数据通信和同步�过程中，失败处理方式。