单体应用与微服务_一个应用既可以当单体又可以当微服务

单体式应用
比较适合于小项目，优点是：
   开发简单直接，集中式管理
   基本不会重复开发
   功能都在本地，没有分布式的管理开销和调用开销
微服务
   将应用分解为小的、互相连接的微服务
   优点：   它解决了复杂性问题。它将单体应用分解为一组服务。虽然功能总量不变，但应用程序已被分解为可管理的模块或服务。这些服务定义了明确的RPC或消息驱动的API边界。微服务架构强化了应用模块化的水平，而这通过单体代码库很难实现。因此，微服务开发的速度要快很多，更容易理解和维护。
   其次，这种体系结构使得每个服务都可以由专注于此服务的团队独立开发。只要符合服务API契约，开发人员可以自由选择开发技术。这就意味着开发人员可以采用新技术编写或重构服务，由于服务相对较小，所以这并不会对整体应用造成太大影响。
   第三，微服务架构可以使每个微服务独立部署。开发人员无需协调对服务升级或更改的部署。这些更改可以在测试通过后立即部署。所以微服务架构也使得CI／CD成为可能。
   最后，微服务架构使得每个服务都可独立扩展。我们只需定义满足服务部署要求的配置、容量、实例数量等约束条件即可。

促进敏捷开发和持续集成部署
放弃传统的强一致性，而转而追求最终一致性

对业务有深入的认识，对系统设计的领域模型、用户行为有足够的理解，领域模型上合理的拆分规划，减少同步远程调用，走消息的异步交互，适当的数据冗余，保证每个被拆分后的微服务之间可以获得更低耦合度
API Gateway，服务间调用，服务发现，服务容错，服务部署，数据调用

接口提供方的限流策略（保护自己不被别人搞死），接口调用方的降级策略（保护业务更高的可用性），接口调用方的熔断策略（保护自己不被别人拖死）

引用：https://didispace.blog.csdn.net/article/details/114687154?spm=1000.2115.3001.4373