随着系统业务的复杂,代码量的增多和新兴的业务加入,为了降低业务,代码和数据库的耦合,我们需要对复杂的系统做肢解和重构,抽出其中复用性较高的模块.所以出现了按服务拆分产品架构

按服务拆分产品架构好处:
业务解耦,方便扩容,方便系统按模块升级,模块重用,开发新业务简单,开发人员可以专注某一业务,方便代码管理,方便数据库优化
按服务拆分产品架构坏处:(分布式服务框架要解决的问题)
每个系统之间的关系变得非常复杂
随着调用的业务增多,底层的模块需要高可用性和并发
需要分布式Session框架支持
分层后增加测试复杂度


项目（子项目）结构，重要实现逻辑，重要技术点描述
关键字:
server:表示一个独立部署的项目(可能会部署多个实例)
node:每个项目的单个实例

文件夹:
aop :提供了面向切面的功能,只要实现了基于注解的性能监控
cache:缓存服务和配置,包括从zookeeper加载服务和全局配置的数据以及持久化这些数据到硬盘
configuration:读取并初始化infogen配置
event_handle:事件回调处理器
http:封装了启动mvc框架和http调用和安全白名单限制
kafka:封装了kafka的接收器
rpc:目前封装了thrift的处理器和异步处理  TODO:需要替换成GRPC
Security:安全相关配置的处理
self_describing:启动时扫描http自描述接口,用于生成文档
server:获取服务相关的类
thrift:thrift自动生成的服务类
tools:常用工具方法
util:基础类
zookeeper:封装了对zookeeper的操作
InfoGen_Jetty:启动jetty服务
InfoGen_Kafka:启动kafka服务
InfoGen_Thrift:启动thrift服务  TODO 需要替换成GRPC
Service:封装了http和rpc类型的调度方法
InfoGen:启动infogen





infogen实现了:
服务的远程调用（RPC,HTTP）
服务的分布式调用链及服务状态跟踪统计
服务的配置管理:包括服务发现,负载均衡及服务依赖管理

一:微服务发布
1. HTTP
.spring mvc(服务映射)
.jetty
.tomcat web容器
2. RPC
.thrift(与spring mvc共用一套服务映射)

二:服务调用代理及客户端软负载
1.HTTP 同步
2.HTTP 异步
3.RPC同步
4.RPC 异步

三:基于Token的认证

四:服务治理
1.服务自描述
2.服务注册中心
3.服务管理网站
4.服务配置推送

五:配置管理
1.全局配置存储
2.全局配置推送

六:服务监控
1.接口执行监控
.平均时间
.频次分布
.超时次数
.Error次数
.总吞吐量
.并发数
.关键事务
.服务器信息
2.接口调用监控
.调用接口分布
.超时比例
.调用失败比例
.各服务间调用情况图
3.分布式追踪系统
.埋监控代码
4.kafka 日志收集

七:基于注解的AOP框架
1.监控日志
*2.缓存
*3.事务

*八:接口测试平台
