从 rpc 说起：

rpc 远程过程调用。 是建立在 socket 之上的一种多进程间的通信机制。

他要实现的目的是以调用本地代码的方式来调用远程代码。 所以它需要一个 stub 透明代理的过程。

实现 rpc 的框架:

最早是sun rpc 。 透明代理 stub模块 对消息的封装， 序列化 反序列化技术。

rmi 。使用 java 的默认序列化机制和动态代理技术。

后来的soap。 消息主题基于xml。由于soap报文复杂所以被淘汰了，对二进制数据不友好要转码。

http rest 是用json格式传递请求和应答参数。 但是已经脱离rpc 因为他无需客户端和服务端的stub代码 调用方式也不再是类似本地的调用方式。

正统的rpc thrift avro zeroc ice。当然下面就仅仅只说thrift 。

rpc框架 需要考虑的问题：

网络异常

复杂数据的编码和解码 对象序列化

tcp连接复用。 心跳检测 超时机制。

多线程 机制。 nio 。

从rpc 到服务治理框架：

应该包含 服务注册和发现。其他比如服务监控。

thrift集成 zk 。才能够实现注册中心和配置中心。

没有zk的话，就仅仅是提供了远程socket通信的一个框架罢了，仅仅能对业务进行拆分 分布，但无法进行服务的 负载均衡 和故障转移。

zookeeper 本身就是一个实现数据一致性的 分布式存储 应用，所以集成了zk的rpc框架，都能通过zk来实现数据一致性。也就是说 注册和下线服务 在zk集群上的数据一致性。客户端调用rpc框架集成的服务 是通过zk来获取服务地址的。服务之间的调用，也是通过zk的。 zk相当于做了一层服务路由的负载均衡。

微服务 框架：

其实就是 强调两个事情。 一个是多个微服务组成，而不是一个单体应用。强调一个服务同时运行在多个进程。

基于http rest为通信机制。 springcloud

基于rpc的 icegrid。

还有一种是基于 容器技术 。 并没有提供特定rpc协议。 比如google的kubernates 。

单体架构的弊端。

风险：

业务系统 运行在一个进程。项目升级 需要重启整个进程，某个模块有问题会导致整个项目无法启动。

维护：

水平扩容问题。 即便有负载均衡 但是粒度大，难以针对性的对某项业务单独扩容。

难以复用服务。

软件架构演变路线:

目的是为了解决单体架构的问题。

soa 面向服务的架构的理念。soa有张蓝图。其核心还是rpc技术 以及服务注册和服务发布模型。

rpc框架。—分布式服务治理框架–微服务框架。

微服务架构 设计理念：

松耦合 的系统。 其实就是采用接口，接口层的松耦合 避免了服务实现的深耦合。整个系统的平衡升级能力得到保障。

轻量级的服务，粒度小，便于快速开发 部署 测试 升级。

平滑扩容。 微服务架构原生的提供了 微服务负载均衡。单体应用也可以负载均衡，但是服务粒度小了，可以单独扩容，具有很强的性能调优能力。

积木式系统。 每个服务被设计成最小粒度的逻辑单元。整个业务就是合理编排这些微服务。新业务上线变成了一个可评估的和预测的计划任务。