程序员人生 网站导航

微服务化架构演进与人员组织

栏目:综合技术时间:2015-02-24 20:56:59

本文来自本人独立博客,更好的浏览体验点击这里


「微服务架构思路对组织影响的进1步思考。」


今年开始系统演变进入了第4个大版本,前两个版本我们采取的单1利用模式,核心开发团队也只有5、6人。
前年团队扩大到了近 20 人左右,单1利用的保护协作本钱已变得不可忽视,服务化拆分时进入第3版时我们做出
的1个选择,但当时拆分粒度其实较粗,方便把团队拆分为几个小组来分别保护不同的服务和子系统。



两年来随着业务的发展,每一个当初拆分的子系统或服务都膨胀到了1定的复杂度。单1进程利用实际承载了数10个
业务服务,单人保护单1服务进程利用开始变得有负担,而类同业务大量需求致使的定制化开发严重拖累团队的生产力,
进1步的微服务化与业务组件平台化将是进入第4版的主题。

微服务的粒度

随着公司运维基础设施(编译、部署、发布、监控和预警)的逐渐成熟为微服务化的生产利用铺平了道路。
微服务拆分遵守了两个纬度,1个是业务服务分级化、目前定为3级(0、1、2),0 级服务为最核心,而越是核心
的业务拆分的职责越单1和正交化,实现功能的最小集,足够的简单单1对确保稳定、性能和控制变更都有莫大好处,
边际本钱递减效应明显。

微服务计划与设计

当我们开始斟酌到底需要撤除哪些服务时,与城市计划有些类似。首先1个城市会化成几个大的片区,
每一个片区承当着城市发展所需要不同功能职责(商业、居住、工业、科技等)。只有大的片区划分是不够的,
仅仅完成了顶层设计,微服务化的设计需进1步深入到这个片区究竟是否需要安置1个 “购物中心”或“学校” 之类,
微服务化设计完成后,每一个微服务的契约与主要职责就应当像 “购物中心”或“学校” 这样的描写那末明确了。


微服务功能职责仅仅是服务契约中的1部份,另外一部份则是非功能规约。例如1个 “购物中心” 的肯定则隐含对
周围的交通流量提出了要求,否则过于拥堵的交通压力会影响 “购物中心” 功能的可用性。
因此当设计1个微服务的契约时,我们需要描写清楚它提供的功能职责、许诺的响应时间散布、承载的最大流量(TPS)等设计要素。


人员角色的变化

按微服务拆分系统后,依照 “服务即产品” 的思路,人员角色将产生变化。
普通工程师从仅仅开发功能到开发、运营服务,工作性质的转变将带来思路和关注点的变化。
每一个服务最少有1个工程师作为负责人,固然能力更强的人可能会负责更多的服务。
大量拆分的微服务带来开发人员交集的减少,对大范围的团队并行开发好处明显。
而服务负责制对个人能力要求更高,自驱动和自学习能力更强的人会得到更多的成长机会,个人成长线路的发展也打开了空间。


这时候团队的构成会变得类似 NBA 球队的组成,工程师的角色类似球员,架构师或技术经理类似主教练,而部门经理则是球队经理。
球员只管打好球,教练负责球员训练、培养与战术安排,经理则掌握着人事权,控制着球员的薪水升迁,招聘到优秀的球员。


1只篮球队场上实际只有5个位置,对应不同服务的负责人,如果人员少于服务分类,实际会有能力强的球员同时打多个位置。
而当人员多于服务分类时,必定有人是首发主力队员,而有人则是后补队员,乃至也有人是长时间坐冷板凳的。
谁能成为首发主力,乃至成长为明星球员这多取决于个人努力、能力和比赛的受欢迎程度。


球队要打出好成绩需要优秀的球员、教练相互默契的配合,这1点也是与按微服务化组织的开发团队相1致的。
固然最好能在更受欢迎比赛上打球。

------分隔线----------------------------
------分隔线----------------------------

最新技术推荐