‘污染’，其实从未停息

 

作为一家传统金融业务起家的公司，由始至终都选择自研系统，这本身就透漏着一种技术情怀。

 

不过情怀归情怀，问题还是有不少，咱们先来谈谈这几年随着好买的业务突飞猛进之后，服务（或叫业务系统）建设与管理中所暴露的痛点：

• 业务条线 - 多：（据不可靠统计）3个事业群，20+个子系统，150+个应用服务，500+个服务接口

• 注册中心 - 散：10+个Zookeeper集群，做个组合要链一堆ZK，测试环境更是一把鼻涕两行眼泪

• 监控方式 - 杂：2个自主研发的监控系统、ELK、日志分析、端到端...

 

 

既然罗列的那么清楚，为什么不去解决它呢？比如说重构不就得了。。来说下为什么这些问题虽然清楚，但却久久不能 “根除” 呢？

1. 技术容量与性能并非最大痛点，业务复杂度高带来的治理成本高是当务之急

2. 研发资源有限，无法做到在业务高速并行阶段，同时兼顾系统的大规模改造

3. 质量关的压力，回归测试依赖于人肉，版本管理带来的隐患等

 

一口气说了那么多‘问题’，想必身临其境的小伙伴肯定清楚，这些点绝非像文字描述的那样轻描淡写，可谓 “谁做谁知道，感觉真奇妙”

 

为了寻找突破，我也不断地和小伙伴们一起探索者，另外自从加入EGO这半年， 也接触了不少大咖，从某这角度说，上面我所谈到的问题和痛点，是具有普遍性的，只不过大家选择的解决路径不同罢了

 

‘治理’，先规范下吧

 

 

困难永远都在，用我们经常提及的一句话来概括下 “持续污染，持续治理，寻找平衡，夹缝中寻找突破”

 

 

 

通过几轮脑暴，我们打算先从 “dubbo源码私有化” 开始，那就先谈谈为什么我们要启动 “dubbo源码私有化”？

 

在此之前，公司内所有的dubbo服务都是“想怎么玩就怎么玩”，也出现了很多的需求和问题，基本都是‘头痛医头脚痛医脚’，解决完就拉倒，所以本次针对这些现象进行以下措施：

• 版本化：基于最新版本2.5.3(2012-10-22) ，近1-2年，各团队对dubbo源码多少修改了一些，版本不一致

• 避风险：修复一些已知的bug

• 技术栈：架构团队对dubbo原理较为熟悉，但对源码逻辑、结构及package tree不够深入

• 自定义：通过封装（或变更）底层源码的方式，达到测试Debug或技术支持

 

是的，我们改动了dubbo的源代码，并对多条业务线的dubbo源码进行了合并及封装、调整，罗列4处改动点：

 

 

 

小伙伴们经过2周的奋战，用漂亮的身手证明了，dubbo源码也不过如此而已~

 

 

 

撸起袖子“建平台”

 

解决了dubbo源码私有化，说白了也只不过将原本不标准的流程变得标准了，顺带的解决了几个BUG，并合了下代码

 

接下去，为了开展“持续治理”，我们开始基于Dubbo建立属于自己的“服务治理平台”~

 

我们给他起了个好听的名字

 

 

规划架构设计图：

 

 

通过HRB平台，帮助我们解决以下问题：

• 集中化：各接各的ZK，各用各的dubbo admin

• 标准化：APP名，接口名比较随意，给统计、自动化测试、管理带来困难

• 强监控：部分业务线使用了dubbo monitor，无法获取‘RPC端到端 ’的各项数据

• 需治理：具不可靠统计，目前dubbo interface已超过500+

• 洞见性（未来展望）：灰度发布、应用分组、限流降级、弹性伸缩等

 

 

这么大的‘梦’要几个夜去圆

 

 

先从成本的角度说下各方的配合与投入：

• 对于平台研发而言，主要的研发资源将投入在管理中心上（预计4周时间），着重满足多业务线、多视角的用户体验、数据体现等热点

• 对于应用研发而言，由于对dubbo完全兼容和适配，将无需接入

• 对于测试与运维而言，只需通过3项工作即可实现平滑过渡：

  1. 替换dubbo包（HRB SDK），修改配置（集成配置中心）

  2. 迁移ZK至新ZK（两种方案：“一把切：全dubbo应用服务覆盖”与“逐步切：挑选应用” ）

  3. 将dubbo Admin下线，使用HRB开始工作

 

 

 

 

多想想，方法总是有的

 

对于好买来说，今年应该是推行‘平台化’以来的第2个年头，有时抬头看看，会觉得很累，路途漫漫，可当你回头看看走过的路，将会觉得成就满满

 

有时我们会抱怨，因为A条件不成立，所以无法达到B目标，其实只要我们多想想，多琢磨琢磨，哪怕是一条缝，应该也会有水珠滴落，只不过有太多的时候我们没有去关注，总觉得无在乎罢了

 

最后通过一张最近正在探讨的“好买中间件（或平台）规划图”表达下美好的期待，我们在路上，在前进~