`
BradyZhu
  • 浏览: 245488 次
  • 性别: Icon_minigender_1
  • 来自: 上海
社区版块
存档分类
最新评论

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

 
阅读更多


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


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



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

微服务的粒度

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

微服务规划与设计

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


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


人员角色的变化

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


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


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


球队要打出好成绩需要优秀的球员、教练相互默契的配合,这一点也是与按微服务化组织的开发团队相一致的。

当然最好能在更受欢迎比赛上打球。


----------------------------

下面是我自己开的一个微信公众号 [瞬息之间],除了写技术的文章、还有产品的、行业和人生的思考,希望能和更多走在这条路上同行者交流,有兴趣可关注一下,谢谢。


分享到:
评论

相关推荐

    java微服务技术分享

    架构演进 中台建设 服务治理 数据治理 研发效能 组织升级 阐述产品技术的升级改造过程及组织升级过程,

    微服务和演进式架构

    在这种方法中,专门有一个架构团队,他们来识别出整个组织中?各个部门应该怎么使用某一组件。某些时候架构团队的业绩甚至还会与其所设计的组件被使用的次数进行挂钩。但是不幸的是,由于架构团队和组件使用团队缺少...

    ArchSummit北京 2019年全球架构师峰会PPT合集(76份).zip

    云原生趋势下的架构演进 云原生互联网架构加速企业数字化转型 亿级数据服务化平台的建设与发展 以K12中文教育为例的多模式教育数据挖掘实践 一站式机器学习平台在AI的实践 业务安全演变和管理解决之道 研发过程度量...

    分布式服务框架原理与实践-李林锋著.pdf

    首先要实现服务化,微服务架构是一种服务化架构风格。《分布式服务框架原理与实践》对如何构建分布式服务化系统,提供了原理分析、关键技术、开发案例以及业界技术对比,非常系统化,不论是学习分布式服务技术还是...

    分布式服务框架原理与实践

    首先要实现服务化,微服务架构是一种服务化架构风格。《分布式服务框架原理与实践》对如何构建分布式服务化系统,提供了原理分析、关键技术、开发案例以及业界技术对比,非常系统化,不论是学习分布式服务技术还是...

    CNUTCon上海 2018年全球运维技术大会PPT合集(34份).zip

    一次微服务架构决策的案例 研发效能演进之路 新思路打造移动端个案综合日志分析系统 网站性能优化 数据库运维发展与实践 容器化交付实践 全链路监控系统(鹰眼)的技术实践 平台自动化运维实践 监控报警平台的设计和...

    微服务概念解析(下)

    在上篇中我们讲到了微服务的几个架构特性,包括通过服务实现组件化、以业务功能为核心进行组织、产品而非项目、智能化端点与傻瓜式流程,在今天的微服务概念解析下篇中,我们将继续讲述微服务的特性,具体分析它的...

    2022年十大数字科技应用趋势.pdf

    云原生通过容器、服务网格、微服务、不可变基础设施和声明式API等关键技术,使松散耦合的系统具有弹性、可管理性和可观察性,能够更低成本、高效地调用各类云计算资源向业务交付应用,推动IT体系向全面云化的新阶段...

    领域驱动模型&CQRS学习

    微服务系统的设计自然离不开DDD(Domain-DrivenDesign,领域驱动设计),它由EricEvans提出,是一种全新的系统设计和建模方法。DDD事实上是针对面向对象分析和设计的一个扩展和延伸,对技术架构进行了分层规划,同时...

Global site tag (gtag.js) - Google Analytics