微服务起因

1：单体应用模式
1.1：概念
从UI(用户界面)，BLL(业务逻辑层)，DAL(数据库访问层)，DB(数据库)都集中在同一个系统中。
1.2：优点
a: 易于开发，在当前工具内就能开发完成（IDE友好） b: 易于测试，不需要依赖其他接口 c: 易于部署
1.3：缺点
a: 缺乏灵活度，因为业务之间耦合严重，需要自上而下的修改，测试也需要等这个应用程序部署之后才能得到结果
b: 部署和启动慢，对应用程序的任意一点的修改都需要重新部署
c: 可靠性太差，任何一个地方出现bug可能拖垮整个应用
d: 使用新的框架较为困难，需要对整体进行修改
2：微服务
2.1 概念
一个服务通常实现了一组不同的特性或者功能，每一个微服务都是一个迷你应用，它自己的六边形架构包括业务逻辑以及多个适配器。
应用程序的每个功能区域现在都由自己的微服务实现。此外，Web 应用程序被分为一组更简单的 Web 应用程序。每个后端服务暴露一个 REST API，大部分的服务消费由其他服务提供的 API。服务也可以使用异步、基于消息的通信。
一些 REST API 也暴露给移动端应用供司机和乘客使用。然而，应用不能直接访问后端服务。相反，他们之间的通信是由一个称为 API 网关（API Cateway）的中介负责。API 网关负责负载均衡、缓存、访问控制、API计量和监控，可以通过使用 NGINX 来实现，换句话说，微服务本身具有自治能力，能够依据负载自己动态扩展业务
2.2 优点
a: 易于开发和维护，由于微服务单个模块就相当于一个项目，开发这个模块我们就只需关心这个模块的逻辑即可，代码量和逻辑复杂度都会降低。
b: 启动较快，相对应启动整个应用架构，启动单个服务的速度较快
c: 局部修改容易部署，如果对外暴露的接口没有修改，只修改内部业务逻辑，则可以很快的修改测试完成之后，进行上线部署。如果有对我接口需要变动则需要周知调用方进行修改。
d: 按需伸缩，原本系统中处理较慢的逻辑部分可以很方便的通过部署到多个机器进行扩容。
2.3 缺点
a: 运维要求较高，相对于单体应用中只需要管理好单个应用程序，而在微服务系统，应用程序较多，环境也更加复杂，保证所有服务都能正常运行也就更加困难。
b: 分布式的复杂性
c: 接口调整成本高，对外接口作为服务之间的沟通桥梁，一旦因为业务需求需要做出调整，相应的调用方同样需要修改，带来较大的工作量。
参考：https://blog.csdn.net/wuxiaobingandbob/article/details/78642020?locationNum=1&fps=1