微服务

背景

业务发展，功能太多，项目臃肿，迭代太慢

架构演进

http rpc

服务间通信基本上是通过两种方式进行通信的http和rpc

• 应用场景
  HTTP由于其通用性，接入代价小的特点主要用于外部服务调用
  内部服务间的调用主要使用RPC

• 性能
  RPC 和 HTTP的数据都是通过TCP进行传输
  通用定义的http1.1协议的tcp报文包含信息比RPC使用的传输协议的tcp报文会多很多，所以其在传输效率上RPC一般来说会高一些

• 接入方式
  HTTP由于其通用性，基本上所有的语言都可以非常方便的访问HTTP服务，服务方不需要了解业务方使用的何种语言。
  RPC可能需要为业务方提供多个开发语言版本的SDK，使业务方可以像在本地一样调用服务，但服务方的开发量较大。
  基本上各个语言都有性能良好的HTTP客户端库，而RPC的需要服务方针对业务方来提供经过测试的性能良好的SDK。

统一的rpc框架

1. 服务标准化：上下游交互通过标准SDK形式划分，通过SDK提供统一的、一站式的服务发现、容错调度、监控采集等，进而降低服务开发、运维成本。
2. 内置服务发现：对于未接入DiSF的模块来说，带来的收益是显而易见的：节点管理标准化、可运维化、快速扩容。
3. 故障摘除：类似下游上线、机器故障、下游过载超时 导致的业务错误将不再存在，对提升业务自身的SLA有较大收益。
4. 标准化日志输出&采集：RPC通道日志将以标准化的形式打印并采集，统一集成到把脉、Metrics等，降低业务的运维负担。

微服务

• 特点：
  应用按业务拆分成服务
  各个服务均可独立部署
  服务可被多个应用共享
  服务之间可以通信

• 好处：
  架构上系统更加清晰
  核心模块稳定，以服务组件为单位进行升级，避免了频繁发布带来的风险
  开发管理方便
  单独团队维护、工作分明，职责清晰
  业务复用、代码复用
  非常容易拓展

• 挑战：
  服务间依赖关系复杂
  更加方便的负载均衡
  动态扩容，缩容
  故障摘除
  服务降级

服务治理

服务注册

• 服务自注册
• 第三方注册

服务发现

• 服务端发现
• 客户端发现

注册发现：动态扩缩容，上游零感知
负载均衡：加权轮询策略
自动探活：10s级健康探测，分钟级故障机器摘除
依赖管理：管理自身消费了哪些下游服务

---

参考

1. 浅谈服务治理与微服务
2. 谈服务发现的背景、架构以及落地方案
3. SOA服务治理方案
4. 微服务介绍
5. [浅谈服务治理与微服务]