a lib for build micro-service
首先定义:我们要解决的问题是什么!!!
为了引申出问题, 我们来看一个典型的系统架构改造的路线
假设,我们是一个电子商务网站
早期为了系统的快熟迭代, ,代码一把撸, 2个月之后一个三层架构的项目就出来了
系统包括三个模块, account, shopping, pay
为了快速发布上线, 全部hosting在同一个web进程之中 部署方案如下:
刚开始还好，用户量少,系统运行一切正常, 不过随者业务的发展 流量越来越大, 单台服务器支持不住了
这个时候,我们开始采用最简单的web负载, 加入一个nginx,系统部署变成了这样的结构(一台nginx负载两台web)
这样的架构暂时是解决了系统负载的问题
其源码结构(代码耦合), 部署方案(单容器多模块)的问题,也很明显的带来几个问题
-
人越来越多, 代码提交频繁, 代码冲突会越来越严重 ,
-
项目越来越多, 项目的依赖会变得混乱 ,project被污染
-
系统总体故障率大幅上涨, 因为是单项目系统, 任何一次的宕机和发布都是全系统影响级别 !!
为了解决这些问题
开始引入SOA模型, 将项目进行分解, 服务化解耦
于是系统架构变成了这样(account /shopping /pay 项目从源码层面剥离到了不同的git repository中, 发布也在不同的hosting中)
在SOA架构引入的过程中也带来了要考虑的两个问题
- 选择什么样的rpc框架(是否需要支持跨平台, 是否采用二进制协议格式)
- 之前account /shopping/pay 都是在同一个solution中, 如今拆分了其公用基础库该如何安放 ?
SOA解耦了web, srv的部署问题之后
公司发展又上了一个台阶了, 这个时候srv开始出现了单台无法支撑的问题
我们又要开始考虑对srv进行负载均衡,如法炮制, 于是我们的部署结构又变成了如下的模样
到目前为止,我们通过了三次系统改造来解决相应的问题
- 使用nginx做web负载优化
- SOA架构 web/srv的分离
- 添加srv-负载均衡,使其支持srv的scale
有了两层的负载均衡之后 它的问题点也同样的明显
- srv节点是一个经常需要进行部署的节点, 上面的部署架构中,并不支持srv动态的扩展, 一旦一个srv多部署了, 就需要在[srv负载均衡器]中进行配置相关的参数让其流量进行负载(很麻烦)
- 所有的rpc请求, 在网络上都多了一跳(client-srv负载均衡-srv), 平均用户的响应时长被拉长了
到目前为止,我们一开始说定义的问题终于出来了
- 要解决srv动态扩容
- 要解决rpc请求直接连接srv,不经过代理, 并且要支持负载均衡
项目需要解决的问题也出来了
- 支持srv动态扩展
- 支持rpc 负载均衡
详情查看readme