描述
微服务不是一种特定的技术，而是一种逻辑概念，是一种设计思想、理念的统一；就像DevOps一样。
其思路不是开发一个巨大的单体式应用，而是将应用分解为小的、互相连接的微服务。一个微服务完成某个特定功能，微服务之间通过REST API通信。一些微服务也会向终端用户或客户端开发API接口，但通常情况下，这些客户端并不能直接访问后台微服务，而是通过API Gateway来传递请求。API Gateway一般负责服务路由、负载均衡、缓存、访问控制和鉴权等任务。
优缺点
优点
- 通过分解模块，解决了复杂性问题，各个团队只要符合服务API契约，便可以自由选择开发技术独立开发，提升效率；
- 独立部署：每个应用之间的部署可以独立，使CI／CD成为可能；
- 独立扩展；
缺点和挑战
- 微服务的大小没有统一标准，业务逻辑应该按照什么逻辑划分，这本身就是经验过程；
- 分布式部署特点带来的复杂性，开发人员需要基于RPC或者消息实现微服务之间的调用和通信；
- 分区的数据库体系和分布式事务，在微服务架构下，不同服务可能拥有不同的数据库。CAP原理的约束，使得我们不得不放弃传统的强一致性，而转而追求最终一致性，这个对开发人员来说是一个挑战。
- 测试工作更加复杂：可能需要兼顾其他依微服务应用；
- 部署的复杂性：微服务由不同的大量服务构成。每种服务可能拥有自己的配置、应用实例数量以及基础服务地址。这里就需要不同的配置、部署、扩展和监控组件。
常用技术
各个服务之间消息通信机制：RPC 、RESTFUL API 等；
略；
现有框架
- Spring Cloud
- Dubbo
- 下一代微服务：Service Mesh？
- Kubernetes + Service Mesh = 完整的微服务框架？
参考资料
https://baijiahao.baidu.com/s?id=1594456998060853977&wfr=spider&for=pc