微服务应用技术总结

为什么要用微服务？

随着业务扩展、人员增长，单体式应用有以下问题：

1. 团队协作效率低下
2. 部署发布慢
3. 业务之间耦合度高，可用性差

微服务的好处

1. 独立部署
2. 独立维护
3. 业务低耦合

单体应用拆分方式

1、纵向拆分是从业务维度进行拆分。标准是按照业务的关联程度来决定，关联比较密切的业务适合拆分为一个微服务，而功能相对比较独立的业务适合单独拆分为一个微服务。

2、横向拆分是从公共且独立功能维度拆分。标准是按照是否有公共的被多个其他服务调用，且依赖的资源独立不与其他业务耦合。

拆分前需要思考的

1、用什么协议通讯
2、如何发布订阅
3、如何监控
4、服务如何治理
5、故障如何定位

一次正常的服务调用

1、【服务注册】首先服务提供者向注册中心注册服务，声明自己能够提供哪些服务以及服务的地址是什么，完成服务发布。
2、【可用服务查询】接下来服务消费者，从注册中心查询所需要调用服务的地址，
3、【调用，序列化和反序列化】调用方以约定的通信协议向服务提供者发起请求，得到请求结果后再按照约定的协议解析结果。

依赖的基础组件：

1. 服务描述：常用的服务描述方式包括 RESTful API、XML 配置以及 IDL 文件三种。
2. 注册中心：解决服务的发布和订阅，工作流程如下：
   • 服务提供者在启动时，根据服务发布文件中配置的发布信息向注册中心注册自己的服务。
   • 服务消费者在启动时，根据消费者配置文件中配置的服务信息向注册中心订阅自己所需要的服务。
   • 注册中心返回服务提供者地址列表给服务消费者。
   • 当服务提供者发生变化，注册中心将变更通知给服务消费者。
     
3. 服务框架
4. 服务监控
   • 指标收集
   • 数据处理
   • 数据展示
5. 服务追踪
   • 首次调用生成requestId
   • 每次调用继续传输requestId
6. 服务治理
   • 单点故障
   • 单idc故障
   • 依赖服务不可用

数据序列化和反序列化

1. 常用的序列化方式分为两类：文本类如 XML/JSON 等，二进制类如 PB/Thrift 等
2. 选型：
   • 数据结构丰富度
   • 跨语言特性
   • 性能：主要看两点，一个是序列化后的压缩比，一个是序列化的速度。以常用的 PB 序列化和 JSON 序列化协议为例来对比分析，PB 序列化的压缩比和速度都要比 JSON 序列化高很多，所以对性能和存储空间要求比较高的系统选用 PB 序列化更合适；而 JSON 序列化虽然性能要差一些，但可读性更好，更适合对外部提供服务。
     Proto Buf https://www.ibm.com/developerworks/cn/linux/l-cn-gpb/index.html

数据监控：

• 监控对象：
  • 客户端监控
  • 接口监控
  • 资源监控
  • 基础监控
• 监控指标：
  • 请求量(QPS)
  • 响应时间 TP90 TP99 TP 999
  • 错误率
• 监控纬度
  • 全局纬度
  • 分机房纬度
  • 单机纬度
  • 时间纬度
  • 核心纬度

服务治理有哪些手段：

• 节点管理：
  • 注册中心主动摘除
  • 服务消费者摘除机制
• 负载均衡
  • 随机算法
  • 轮训算法
  • 最少活跃调用算法
  • 一致性hash算法
• 路由规则：
  • 灰度发布
  • 多IDC访问问题
  • 配置方案：
• 服务容错的几个手段：
  • FailOver
  • FailBack
  • FailCache
  • FailFast

注册中心选型：

选型基本要求：

1. 高可用
   • 多IDC部署
   • 集群部署

2.数据一致性：多数据中心数据保持一致

CAP 理论：即同时满足一致性、可用性、分区容错性这三者是不可能的，其中 C（Consistency）代表一致性，A（Availability）代表可用性，P（Partition Tolerance）代表分区容错性。

CP 型注册中心，牺牲可用性来保证数据强一致性，最典型的例子就是 ZooKeeper，etcd，Consul 了。ZooKeeper 集群内只有一个 Leader，而且在 Leader 无法使用的时候通过 Paxos 算法选举出一个新的 Leader。这个 Leader 的目的就是保证写信息的时候只向这个 Leader 写入，Leader 会同步信息到 Followers，这个过程就可以保证数据的强一致性。但如果多个 ZooKeeper 之间网络出现问题，造成出现多个 Leader，发生脑裂的话，注册中心就不可用了。而 etcd 和 Consul 集群内都是通过 raft 协议来保证强一致性，如果出现脑裂的话， 注册中心也不可用。

AP 型注册中心，牺牲一致性来保证可用性，最典型的例子就是 Eureka 了。对比下 Zookeeper，Eureka 不用选举一个 Leader，每个 Eureka 服务器单独保存服务注册地址，因此有可能出现数据信息不一致的情况。但是当网络出现问题的时候，每台服务器都可以完成独立的服务。