「微服务架构思路对组织影响的进一步思考。」
今年开始系统演化进入了第四个大版本，前两个版本我们采用的单一应用模式，核心开发团队也只有五、六人。
前年团队扩张到了近 20 人左右，单一应用的维护协作成本已变得不可忽视，服务化拆分时进入第三版时我们做出
的一个选择，但当时拆分粒度其实较粗，方便把团队拆分为几个小组来分别维护不同的服务和子系统。
两年来随着业务的发展，每个当初拆分的子系统或服务都膨胀到了一定的复杂度。单一进程应用实际承载了数十个
业务服务，单人维护单一服务进程应用开始变得有负担，而类同业务大量需求导致的定制化开发严重拖累团队的生产力，
进一步的微服务化与业务组件平台化将是进入第四版的主题。
微服务的粒度
随着公司运维基础设施（编译、部署、发布、监控和预警）的逐步成熟为微服务化的生产应用铺平了道路。微服务拆分遵循了两个纬度，一个是业务服务分级化、目前定为三级（0、1、2），0 级服务为最核心，而越是核心
的业务拆分的职责越单一和正交化，实现功能的最小集，足够的简单单一对于确保稳定、性能和控制变更都有莫大益处，
边际成本递减效应明显。
微服务规划与设计
当我们开始考虑到底需要拆除哪些服务时，与城市规划有些类似。首先一个城市会化成几个大的片区，每个片区承担着城市发展所需要不同功能职责（商业、居住、工业、科技等）。只有大的片区划分是不够的，
仅仅完成了顶层设计，微服务化的设计需进一步深入到这个片区到底是否需要安置一个 “购物中心”或“学校” 之类，
微服务化设计完成后，每个微服务的契约与主要职责就应该像 “购物中心”或“学校” 这样的描述那么明确了。
微服务功能职责仅仅是服务契约中的一部分，另一部分则是非功能规约。例如一个 “购物中心” 的确定则隐含对
周围的交通流量提出了要求，否则过于拥堵的交通压力会影响 “购物中心” 功能的可用性。
因此当设计一个微服务的契约时，我们需要描述清楚它提供的功能职责、承诺的响应时间分布、承载的最大流量（TPS）等设计要素。
人员角色的变化
按微服务拆分系统后，按照 “服务即产品” 的思路，人员角色将发生变化。普通工程师从仅仅开发功能到开发、运营服务，工作性质的转变将带来思路和关注点的变化。
每个服务至少有一个工程师作为负责人，当然能力更强的人可能会负责更多的服务。
大量拆分的微服务带来开发人员交集的减少，对于大规模的团队并行开发好处明显。
而服务负责制对个人能力要求更高，自驱动和自学习能力更强的人会得到更多的成长机会，个人成长路线的发展也打开了空间。
这时团队的构成会变得类似 NBA 球队的组成，工程师的角色类似球员，架构师或技术经理类似主教练，而部门经理则是球队经理。
球员只管打好球，教练负责球员训练、培养与战术安排，经理则掌握着人事权，控制着球员的薪水升迁，招聘到优秀的球员。
一只篮球队场上实际只有五个位置，对应不同服务的负责人，如果人员少于服务分类，实际会有能力强的球员同时打多个位置。
而当人员多于服务分类时，必然有人是首发主力队员，而有人则是后补队员，甚至也有人是长期坐冷板凳的。
谁能成为首发主力，甚至成长为明星球员这多取决于个人努力、能力以及比赛的受欢迎程度。
球队要打出好成绩需要优秀的球员、教练相互默契的配合，这一点也是与按微服务化组织的开发团队相一致的。
当然最好能在更受欢迎比赛上打球。
----------------------------
下面是我自己开的一个微信公众号 [瞬息之间]，除了写技术的文章、还有产品的、行业和人生的思考，希望能和更多走在这条路上同行者交流，有兴趣可关注一下，谢谢。
