一、基础
来自亚马逊的文档
1.什么是微服务？
微服务是一种开发软件的架构和组织方法，其中软件由通过明确定义的 API 进行通信的小型独立服务组成。这些服务由各个小型独立团队负责。
微服务架构使应用程序更易于扩展和更快地开发，从而加速创新并缩短新功能的上市时间。
2.微服务架构对比整体式架构有何优势？
通过整体式架构，所有进程紧密耦合，并可作为单项服务运行。这意味着，如果应用程序的一个进程遇到需求峰值，则必须扩展整个架构。随着代码库的增长，添加或改进整体式应用程序的功能变得更加复杂。这种复杂性限制了试验的可行性，并使实施新概念变得困难。整体式架构增加了应用程序可用性的风险，因为许多依赖且紧密耦合的进程会扩大单个进程故障的影响。
使用微服务架构，将应用程序构建为独立的组件，并将每个应用程序进程作为一项服务运行。这些服务使用轻量级 API 通过明确定义的接口进行通信。这些服务是围绕业务功能构建的，每项服务执行一项功能。由于它们是独立运行的，因此可以针对各项服务进行更新、部署和扩展，以满足对应用程序特定功能的需求。
3.微服务的特性？
自主性
可以对微服务架构中的每个组件服务进行开发、部署、运营和扩展，而不影响其他服务的功能。这些服务不需要与其他服务共享任何代码或实施。各个组件之间的任何通信都是通过明确定义的 API 进行的。
专用性
每项服务都是针对一组功能而设计的，并专注于解决特定的问题。如果开发人员逐渐将更多代码增加到一项服务中并且这项服务变得复杂，那么可以将其拆分成多项更小的服务。
4.微服务的优势？
敏捷性
微服务促进若干小型独立团队形成一个组织，这些团队负责自己的服务。各团队在小型且易于理解的环境中行事，并且可以更独立、更快速地工作。这缩短了开发周期时间。显著提升整个团队的总业务吞吐量。
灵活扩展
通过微服务，可以独立扩展各项服务以满足其支持的应用程序功能的需求。这使团队能够适当调整基础设施需求，准确衡量功能成本，并在服务需求激增时保持可用性。
轻松部署
微服务支持持续集成和持续交付，并可以在无法正常运行时回滚。由于故障成本较低，因此可以大胆试验，更轻松地更新代码，并缩短新功能的上市时间。
技术自由
微服务架构允许团队可以自由选择最佳工具来构建自己的服务。
可重复使用的代码
将软件划分为小型且明确定义的模块，让团队可以将功能用于多种目的。专为某项功能编写的服务可以用作另一项功能的构建块。这样应用程序就可以自行引导，因为开发人员可以创建新功能，而无需从头开始编写代码。
弹性
服务独立性增加了应用程序应对故障的弹性。在整体式架构中，如果一个组件出现故障，可能导致整个应用程序无法运行。通过微服务，应用程序可以通过降低功能而不导致整个应用程序崩溃来处理总体服务故障
二、微前端（前端微服务）架构
1.前端架构演变简述
任何的架构概念都不会是凭空出现，都有其历史合理性，简单了解一下前端架构演变的历史，可以帮助理解微前端架构。
技术的架构演变有一条核心驱动力，那就是降本增效。
第一阶段：前后端一体
最开始，Web应用的功能非常简单，界面的展示与后端逻辑的处理并没有分离开来，其实是没有前后端之分的，服务器会将html渲染完成，返回给浏览器，浏览器负责展示。
第二阶段：SPA初期
随着时间的推移，一个公司或者团队可以提供的服务越来越多样化，因为开发维护成本的原因，大部分公司采用将一种将多个不同的服务集中在一个大平台上统一对外开放的概念，这就是SPA的出现。MVC解决方案在此时是主流方案。
第三阶段：前后端分离的SPA
日益复杂的应用对工程师个人提出了更高的要求，更加强调专人专事，这就出现了围绕数据的处理和展示的职位的划分，当然还有测试等其他工程师职位，那此时技术上前后端一体的架构已经不能满足现状了，为了能够明确应用职责，将数据的处理和展示彻底分开，前后端分离的设计模式逐渐流行，前端需要展示的数据通过网络请求发送给服务器，得到数据之后，再有前端进行渲染展示，这样服务器只负责提供对应的数据即可，服务器不再负责页面渲染的工作。
此前主流的MVC方案演变为MVVM，基于此业内也出现了一些新的前端框架，具代表性的有Vue等，React也是用于实现前后端分离的前端框架，但React专注于View层，需要配合诸如redux等进行状态（数据）管理。
第四阶段：微前端（前端微服务）
前后端分离后，后端面临日益繁杂的功能，首先提出并采用了微服务架构，后端对比前端，在使用微服务架构上有天然优势，因为前端SPA应用中，不同模块之间总避免不了UI展示和交互逻辑的牵连和耦合，前端进行功能的独立分割（开发、发布、运维都独立）但却不影响用户体验，其中困难较后端要大，前后端分离后，前后端通过各种不同功能的接口通信，后端已经具备了采用微服务架构的基础。
随着SPA变得更加复杂，维护和迭代效率达到瓶颈，采纳后端微服务这一架构概念的微前端架构出现了，同时伴随着团队组织架构的调整。微前端背后的理念是将一个网站或者 Web App 当成特性的组合体，每个特性都由一个独立的团队负责。每个团队都有擅长的特定业务领域或是它关心的任务。这里，一个团队甚至可以是跨职能的，它可以端到端，从数据库到用户界面完整的开发它所负责的功能，当然也可以有自己的测试工程师等专职人员。
2.微前端的优势
同上文微服务的优势
3.如何实现微前端？
技术架构
从架构模式上讲，根据微前端应用间的关系来看分为两种：
基座模式。通过一个主应用来管理其他应用。设计难度小、方便实践，但是通用度低。自组织模式。应用之间是平等的，不存在相互管理的模式。设计难度大，不方便实施，但是通用度高。
从技术实践上，微前端架构可以采用以下几种方式进行：
路由分发式。通过 HTTP 服务器的反向代理功能，将请求路由到对应的应用上。前端微服务化。在不同的框架之上设计通信和加载机制，以在一个页面内加载对应的应用。微应用。通过软件工程的方式，在部署构建环境中，把多个独立的应用组合成一个单体应用。微件化。开发一个新的构建系统，将部分业务功能构建成一个独立的 chunk 代码，使用时只需要远程加载即可。前端容器化。将 iframe 作为容器来容纳其他前端应用。应用组件化。借助于 Web Components 技术，来构建跨框架的前端应用。
团队架构
和微服务一样，与微前端相适应的团队，应该是垂直划分的，要和微前端中的子应用功能相对应，理论上要可以支撑一个独立子应用的全生命周期管理（开发、测试、发布、运维）。
