微服务系列-架构

• 模块即服务；
• 微服务使用库，库定义成内存里面的调用，微服务定义成web请求或远程调用；
• 独立可部署；
• 接口调用；
• 缺点是远程调用比本地重很多；
• 按业务逻辑进行分配；
• 分成产品而不是项目；
• 使用http请求或消息；
• 一般使用消息来做轻量级消息总线，做异步，关键是统一协议，例如：RMQ或AMQP；
• 分散管理；
• 各个模块可以采用各种实现来做；
• 可以使用容忍读策略和消费契约来解决上下游通信问题；
• 使用最终一致性，并用补偿策略来解决问题，如：消息队列；
• 持续交付和持续集成；
• 同步调用非常有害；

建立服务网关：

有了网关支持，可以根据需要把流量在新老系统之间切换。采用zk实现，所有服务注册到zk上，网关根据zk注册来将用户请求按比例分配到工作机上。在网关可以实现熔断和限流。

业务细分，读写分离：

接口拆分，微服务化：

将庞大系统按服务拆分，创建project。每个project不会超过5个接口，这些结构都是高内聚，同功能的，仅仅参数不同。拆分之后每个实现类都很少，不超过10个，代码行数不超过300行。

完善基础设施：

微服务环境上，采用git做版本控制，gitlab做代码审核，jenkins支持自动发布和上线。

• 采用spring cloub作为我服务框架；
• 系统拆分2大层，不包括前端系统，一层对外提供web服务，采用http/json。一层是业务逻辑，供web服务层调用，采用rpc来实现；
• web层采用spring boot实现；
• rpc层采用thrift来实现；
• 网关使用nginx+lua实现load balance，限流，服务自动发现；
• 基础设施，git+gitlab+jenkins；

微服务拆分：

rpc层微服务按表来拆分，自己连一个数据库，分为两层：数据访问层和业务逻辑层，如果业务逻辑层薄，可合并成一层；