微服务 - microservice

　　 微服务是指提供单个业务功能的服务 。无独立进程，采用轻量级的通信协议，独立部署且无集中式管理。

​ 技术角度上看，就是把一个传统的复杂软件架构拆分为若干小而独立运行（有自己的端口）微服务组成，这些独立处理组件之间通讯是通过与语言无关的 API 进行。这种做法可以将具体业务拆分为多个模块，提供充分的灵活性，大大提高了项目生命周期和开发效率。

特性

　　每个微服务组件都有自己分配的存储 内存和 CPU 资源，这就使得硬件利用更加易于优化和跟踪开，只要遵循微服务之间的 API 规范，微服务组件就可以组成一个完整的服务。这个服务的复杂性和扩展性是良好的，更新其中一个微服务组件不会引起连锁反应，因为微服务之间是松耦合的。

　　

容器技术与微服务

​ 因为有很多应用和服务部署在基于云主机的环境中，微服务架构将会严重依赖容器技术，容器隔离了微服务处理过程，将一个应用切分为一个个小的实例，这些容器中的小实例有自己的端口和虚拟化环境。广泛使用的容器技术是 Docker。

　　微服务架构不只是传统服务变微变小。微服务两个显著特点是：微服务本身是无状态的；微服务之间很少可变共享。可以设想一下，如果微服务之间可以共享，那么带来两个问题：微服务团队之间需要合作，因为共享的是一个统一数据库，如果这种共享没有带来沟通成本，没有破坏一个团队就能搞定的宗旨，那么这种共享数据库也是可以考虑，但是这种情况很少，大部分团队因为共享问题破坏了独立性；再者，微服务如果使用 Docker 分别打包在一个容器中，这些容器可能是跨不同基础设施部署，部署方式很灵活，是一种 cloud native 应用，而共享数据库属于底层基础设施，显然提高了部署难点。

　　另外，传统服务之间通讯无论是 RPC/RMI 或是 Http/RESTful 都是同步的，而微服务之间通信最好是异步的或 reactive 的，也就是非同步的。根据 FLP 不可能原理 网络默认是不可靠的，RPC 在一旦发生网络堵塞会连环爆炸，事后监控并不能根本解决这个问题，需要参考 CAP 定理 进行平衡设计，引入事件驱动或 Pub/Sub 消息方式能在提高网络容错性的同时，保证数据最终一致性，柔性事务是微服务环境的主要选择。

　　传统服务变成铁板一块经常是因为事务处理要求，某个服务方法的代码很多，需要塞在同一个事务边界内，虽然这带来了高一致性的，但是扩展性比较差，因为同一个事务边界内的动作无法分离到几个微服务中，因此，使用微服务必须积极拥抱最终一致性，对分布式系统以及 CAP 定理有一定理解。当然，这些都是必须有多个微服务调用的情况下才需要考虑，由于微服务粒度小且专一，可以通过组合替代共享继承的思路，容忍代码有一定的重复性。