java软件架构浅析

从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框架。---分布式服务治理框架--微服务框架。

微服务架构设计理念：
松耦合的系统。 其实就是采用接口，接口层的松耦合 避免了服务实现的深耦合。整个系统的平衡升级能力得到保障。
轻量级的服务，粒度小，便于快速开发 部署 测试 升级。
平滑扩容。 微服务架构原生的提供了 微服务负载均衡。单体应用也可以负载均衡，但是服务粒度小了，可以单独扩容，具有很强的性能调优能力。
积木式系统。 每个服务被设计成最小粒度的逻辑单元。整个业务就是合理编排这些微服务。新业务上线变成了一个可评估的和预测的计划任务。