云架构之微服务

开头先介绍一下微服务的优点：实现跨团队的解藕，实现更高的并发（目前单机只能实现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提供了注册发现的服务。客户端获取到配置文件后也会写入磁盘。