再谈微服务

传统方式 VS 微服务

传统开发方式遇到的问题：

• 开发效率低：所有的开发在一个项目改代码，递交代码相互等待，代码冲突不断。
• 代码部署难：代码功能耦合在一起，新人不知道如何下手。
• 部署不灵活：构建时间长，任何小的修改必须重新构建整个项目。
• 稳定性不高：一个问题往往导致整个应用挂掉。
• 扩展性差：无法满足高并发情况下业务需求。

简单说：

微服务的目的是有效的拆分应用，实现敏捷开发部署。

官方对于微服务的定义：

• 一系列独立服务共同组成系统；
• 单独部署，跑在自己的进程中；
• 每个服务为独立业务开发；
• 分布式管理；

微服务标准：

• 分布式服务组成系统；
• 按照业务而不是技术划分组织；
• 做有生命的产品而不是项目；
• 自动化运维；
• 容错；
• 快速演化；

使用微服务的问题：

• 客户端如何访问微服务；
• 服务之间如何通信；
• 服务多了怎么找？
• 服务挂了怎么办？

客户端访问微服务

之前的UI和服务都是本地的，UI可以直接调用，现在按功能拆分成独立的服务，每个服务都跑着独立的虚拟机上的JAVA进程中。后台有N个服务，客户端就需要记住N个服务，一个服务下线/更新/升级，前台都需要重新部署。N个服务的调用也是不小的网络开销，用户授权管理需要统一。

所以一般在客户端和N个服务之间，建立代理或者API Gateway：

• 提供统一服务入口，让服务对客户端透明；
• 聚合后台服务，节省流量，提升性能；
• 提供安全，过滤，控流等API管理功能；

服务之间如何通信

所有服务都是独立的JAVA进程跑在独立的虚拟机上，所以服务间的通信是IPC，有很多成熟的解决方案，通用的有两种方式：

• 同步调用：
  • REST （JAX-RS，Spring Boot）
  • RPC （Thrift，Dubbo）
• 异步消息调用(Kafka，Notify，MetaQ)

同步调用：

简单，一致性强，容易出调用问题，性能体验会差一些，调用层次多的时候可能耗时。 REST基于HTTP，更易实现，更易接受，服务端实现更加灵活，各个语言都能支持，同时能跨客户端，对客户端没有特殊要求，使用更广。 RPC有自己的优点，传输协议更高效，安全性更可控。

异步调用：

降低系统服务之间耦合，为调用之间建立缓冲，确保消息积压不会冲垮被调用方； 需要付出一致性代价，后台服务一般需要实现幂等性，因为消息发送出于性能考量一般会重复； 需要引入独立的broker，对broker分布式管理也是一个挑战；

服务多了怎么找？

一般一个服务有多份拷贝，做负载均衡。一个服务随时可能下线，也可能面临访问压力时增加新服务节点。 服务之间如何感知？服务如何管理？

• 基于zookeeper框架实现服务注册分布式管理。
• 客户端做：优点是架构简单，扩展灵活，只对服务注册器依赖。缺点是客户端需要维护所有调用服务地址，有技术难度，可使用Dubbo。
• 服务端做：优点是简单，所有服务对前台调用透明，一般在小公司云服务上部署采用较多。

服务多了挂了怎么办？

单体应用风险是鸡蛋放在一个篮子中，分布式的特征是网络不可靠。所以当系统由一些列服务调用链组成的时候，必须确保任何环节不出问题而影响整个链路。手段如下：

• 重试机制；
• 限流；
• 熔断；
• 负载均衡；
• 降级（本地缓存）；

最后提到微服务离不开DevOps和Docker，理解微服务架构是核心，devops和docker是工具，是手段。