微服务好处：实现跨团队的解藕，实现更高的并发（目前单机只能实现c10k）不用在拷贝代码，基础服务可以公用，更好的支持服务治理，能够更好的兼容云计算平台。
rpc:向调用本地方法一样调用远程函数。
客户端：一般利用动态代理生成一个接口的实现类，在这个实现类里通过网络把接口名称，参数，方法序列化后传出去，然后控制同步调用还是异步调用，异步调用需要设置一个回调函数，客户端还需要维护负载均衡，超时处理，连接池管理等，连接池维护了和多个server的连接，靠此做负载均衡，当某个服务器宕机后去除该连接。请求上下文维护了请求ID和回调函数，超时的请求当回复报文到达后由于找不到请求上下文就会丢弃。
服务端：维护连接，网络收到请求后反序列化获得方法名称，接口名称，参数名称后通过反射进行调用，然后将结果在传回客户端。
序列化的方式：一种是只序列化字段的值，反序列化的时候重新构建对象在把值设置进去，另外一种方式直接将整个对象的结构序列化成二进制，前者节省空间，后者反序列化速度快，目前的序列化框架也是在反序列化时间和占用空间之间权衡。有点类似哈夫曼编码，或者数据库怎么存储一行一行的数据。
CAP
C 一致性 A 可用性 P 分区容忍性 可以简单地这样理解：MySQL 单机是C 主从同步复制 CP 主从异步复制 AP
Zookeeper 选择了P，但是既没有实现C也没有实现A 而是选择最终一致性，可以在多个节点上读取，但是只允许一个节点接受写请求，其他节点接收的写请求会转发给主节点，只要过半节点返回成功就会提交，如果一个客户端连接的正好是没有被提交的follower节点，那么这个节点上读取到的数据就是旧的，这样就出现了数据的不一致，所以没有完全实现C，由于需要过半节点返回成功才提交，如果超过半数返回失败或者不返回，那么zookeeper将出现不可用，所以也没有完全实现A
当然衡量一个系统是CP还是AP，可以根据他牺牲A更多还是牺牲C更多，而ZK其实就是牺牲了A来满足C，当超过集群半数的节点宕机后，系统将不可用，这也是不建议使用zk做注册中心的原因。
CAP理论只是描述了在分布式环境中一致性，可用性，分区容忍不能同时满足，并没有让我们一定要三选二，由于网络分区在分布式环境下是不可避免的，所以为了追求高可用，往往我们会牺牲强一执行，采用弱一致性和最终一致性的方案 也就是著名的BASE理论，而base理论其实是针对传统关系型数据的ACID而言的，而ACID的提出是基于单节点下的，而在分布式环境下，如何协调数据一致性，也就是在数据的隔离级别上做出取舍，而即使是单机的关系型数据库也为了提高性能，也就是可用性，定义了隔离级别，去打破ACID里面的强一致性C，当然数据库也是为业务服务的，某些业务或者说大部分业务都没有强一致性的需求。
发布与部署：目前的大部分公司采用下面的部署方式
