开头先介绍一下微服务的优势：实现跨团队的解藕，实现更高的并发（目前单机只能实现c10k）不用在拷贝代码，基础服务可以公用，更好的支持服务治理，能够更好的兼容云计算平台。
rpc:向调用本地方法一样调用远程函数
客户端：一般利用动态代理生成一个接口的实现类，在这个实现类里通过网络把接口名称，参数，方法序列化后传出去，然后控制同步调用还是异步调用，异步调用需要设置一个回调函数，客户端还需要维护负载均衡，超时处理，连接池管理等，连接池维护了和多个server的连接，靠此做负载均衡，当某个服务器宕机后去除该连接。请求上下文维护了请求ID和回调函数，超时的请求当回复报文到达后由于找不到请求上下文就会丢弃。
服务端：维护连接，网络收到请求后反序列化获得方法名称，接口名称，参数名称后通过反射进行调用，然后将结果在传回客户端。
序列化的方式：一种是只序列化字段的值，反序列化的时候重新构建对象在把值设置进去，另外一种方式直接将整个对象的结构序列化成二进制，前者节省空间，后者反序列化速度快，目前的序列化框架也是在反序列化时间和占用空间之间权衡。有点类似哈夫曼编码，或者数据库怎么存储一行一行的数据。
注册中心
一般有三种模式，f5做集中式代理，客户端嵌入式代理例如dubbo，还有一种是综合上面两种，多个客户端共用一个代理，代理作为一个独立进程部署在和客户端服务器同一台物理机上，servicemesh就是这种模式。
配置中心
配置中心的需求：保证高可用，实时通知，灰度发布，权限控制，一键回滚，环境隔离（开发 测试 生产）目前的开源实现：nacos disconf apollo。
disconf:scan模块扫描注解和监听器，store模块将远程获取到的配置存储到本地，本地一个job检测配置是否有变化，有变化就通知监听器，fetch模块从远程通过http获取配置，watch模块监听zookeeper上节点的变化，有变化就会调用fetch进行获取.
apollo：四个模块：portal 作为一个管理后台，提供管理员操作的入口。 有独立的数据库。 adminservice 提供配置的修改和发布服务的底层服务，和 configservice 公用一个数据库configdb，每次修改配置就会往数据库里插入一条记录releasemessage，configservice 用一个定时任务去扫描数据库是否有新的releasemessage，有的话就通知客户端，而客户端采用定时轮询的方式去查询 configservice 是否有新消息，这里采用 deferredresult 异步执行。eruka为adminservice和configservice提供了注册发现的服务。客户端获取到配置文件后也会写入磁盘。