babel: yet another rpc, but far beyond rpc（下）

（图片源自网络）

4框架生态

实际上，在做babel的同时，我也在探索如何更好的利用技术工具来影响团队组织架构。以babel举例，实际上整个框架生态分为三类人：

业务研发。

在框架上提供服务，或调用他人的服务。由于绝大部分的通讯细节已经封装好。业务研发可以更加专注于他的业务方面的逻辑。

框架研发。

研发babel通讯框架，以及其支撑的其他框架，比如监控报警等。框架的研发更多的关注与系统底层，比如稳定性、性能、各个service的数据积压等。

架构师。

这个是最重要的角色。如果说整个公司的系统就是一张图，那么框架研发就提供了纸和笔——业务研发提供了一个一个点，但是是孤立的，架构师则可以以点连线，完成整张图。
在这里，架构师需要关注很多整体上的指标和大局，比如谁和谁连，实例数多少，是否持久化，等等（babel service的schema由架构师决定）。可以这么说，babel给架构师提供了一个可以去描绘大系统框架的技术手段，从而避免了长期空对空的局面。现实中，见过好多不会写代码的架构师，主要原因就是缺乏这类供架构师使用的工具。

在公司内部，从一开始我们就做类似的划分。babel不仅仅是用来做系统组件间的解耦；同时也是不同角色人的解耦工具。

5未来的脚步

从个人的角度看，babel目前也才堪堪能用，只做到了30%的完成度，要成为一个完整和成熟的系统，还有很多路要走——

• 在现有的基础上尝试做workflow功能。babel重合了部分storm的功能，希望能做更多的覆盖。

• 着手central config的开发。目前service的配置与分发还不能做到自动化，有手工工作量。长远做集中的配置管理分发是必须的。

• 完成zeromq的后端实现。对于低延迟、本地应用来说是必须的。

• 完成自动化发布、部署，将整个系统做一个统一的整体。

• 研究弹性伸缩方面的非功能性扩展。

• 考虑增加熔断等自我保护机制。