(图片源自网络)
4框架生态
实际上,在做babel的同时,我也在探索如何更好的利用技术工具来影响团队组织架构。以babel举例,实际上整个框架生态分为三类人:
业务研发。
在框架上提供服务,或调用他人的服务。由于绝大部分的通讯细节已经封装好。业务研发可以更加专注于他的业务方面的逻辑。
框架研发。
研发babel通讯框架,以及其支撑的其他框架,比如监控报警等。框架的研发更多的关注与系统底层,比如稳定性、性能、各个service的数据积压等。
架构师。
这个是最重要的角色。如果说整个公司的系统就是一张图,那么框架研发就提供了纸和笔——业务研发提供了一个一个点,但是是孤立的,架构师则可以以点连线,完成整张图。
在这里,架构师需要关注很多整体上的指标和大局,比如谁和谁连,实例数多少,是否持久化,等等(babel service的schema由架构师决定)。可以这么说,babel给架构师提供了一个可以去描绘大系统框架的技术手段,从而避免了长期空对空的局面。现实中,见过好多不会写代码的架构师,主要原因就是缺乏这类供架构师使用的工具。
在公司内部,从一开始我们就做类似的划分。babel不仅仅是用来做系统组件间的解耦;同时也是不同角色人的解耦工具。
5未来的脚步
从个人的角度看,babel目前也才堪堪能用,只做到了30%的完成度,要成为一个完整和成熟的系统,还有很多路要走——
在现有的基础上尝试做workflow功能。babel重合了部分storm的功能,希望能做更多的覆盖。
着手central config的开发。目前service的配置与分发还不能做到自动化,有手工工作量。长远做集中的配置管理分发是必须的。
完成zeromq的后端实现。对于低延迟、本地应用来说是必须的。
完成自动化发布、部署,将整个系统做一个统一的整体。
研究弹性伸缩方面的非功能性扩展。
考虑增加熔断等自我保护机制。
**粗体** _斜体_ [链接](http://example.com) `代码` - 列表 > 引用
。你还可以使用@
来通知其他用户。