微服务与中台的思考

微服务与业务中台这两种分布式的架构的具体实践，都是现在技术圈非常火的话题。先介绍一下我对两者核心理念的看法：

很多人认为，微服务和中台架构的核心是为了拆分，将大问题拆分成小问题，大问题不好一次解决，但是拆分成一个个小问题后，每个小问题都单独解决就简单很多，这个跟我们常用的思维方法“分析”是一致的。但是我会反问，难道没有微服务和中台，我们的系统就没有拆分吗？举例，在代码重构时，有经验的程序员都会将常用的代码片段重构为公用函数；在业务对象设计是，都会将具有独立业务意义的业务设计成一个独立的类。

所以我认为，微服务和中台的核心核心价值是：抽象、积累、重用和自治；
抽象、积累和重用是一个递进的阶段，抽象是第一步，逐步积累很多的功能，是为了新业务的重用；如阿里的淘宝，很多业务功能是在很多业务系统中都会使用的，如订单、用户、商品等，如果没有业务系统都做自己的订单功能，那企业内部的资源浪费就太多了，所以将订单功能抽象成中台业务；当订单、用户、商品等功能都抽象并积累成中台后，那阿里再开发新的业务（如聚划算）就效率很高了，因为聚划算平台需要新造的轮子只有很少的部分；

自治，从技术上将功能微服务化、中台化后，必然的，对应的组织架构也会形成不同的团队维护每个微服务和中台。每个团队相对是独立的，因为各自维护独立的微服务和中台的全生命周期，这个团队会对自己维护的业务更有归属感，形成自治，从而激发团队的主观能动性；这样自然的形成了互联网企业想要的平面化管理，且每个团队有很大的自主性，释放了各个团队的创新能力和主动性，减少了企业从上至下的管理负担。

然而我一直认为，对于这两种架构，关键点并不在技术上，而在于以下两个方面：

1. 决策
2. 组织管理

决策：是指决定是否将原来的单体应用转换为微服务架构或者中台架构；在决定了转换后，还需要决定转换的程度，例如有多少业务、每个业务中有多少功能，要转成微服务或者业务中台，简而言之，这是0、1或者0到1之间的灰度（现在灰度也是一个比较火的话题）的选择。因为微服务及业务中台架构，相比单体架构有很多的优势，但是同时也有很多的劣势，并不是每个公司、每种业务模式、每种业务场景都适合采用的，在不合适的业务和场景下采用，很可能弊大于利。弊端如：组织之间的沟通协作（第二个方面会描述）、服务器部署及维护的成本等。

组织管理：微服务、中台架构实现后会自然而然的形成很多独立的维护团队；当新开发一个业务功能，整个业务流程会涉及多个微服务或业务中台时，自然会涉及到多组织之间的协调、沟通，因为业务发起方（一般是业务产品团队）需要调动多个团队的资源进行讨论、设计、实现和部署；往往会造成，在单体系统内2-3周就能完成的功能，在微服务、中台架构下，2-3周能完全资源的协调就很不错了，这样的后果是导致开发效率底下，严重的还会影响整体团队的积极性。

要应对微服务、中台架构下多组织协调管理的问题，我有三个建议：

1. 组织内要使用合适的研发管理工具，能满足任务的全生命周期（业务分析、设计、开发、测试、部署）且能满足多组织之间的沟通和资源分配，现在常用的研发管理工具，如JIRA、禅道，并不能百分百的满足这种需求；

2. 建立有效的激励机制。常用的研发团队激励机制，都是针对单一团队内部的，很少跨团队的（360环评是其他团队评价一个团队，并不是一个业绩跨团队考核）；所以可以考虑建立如经销商体系一样的绩效体系，考虑每个团队对这个业绩的贡献度进行考核和激励，从而来激发其他团队参与的积极性；

3. 拓展团建。常见的团队都是针对单一团队的，但是忽略了团队间、特别是每个团队负责人之间的团建。已我以前任职的日立咨询为例，他们有一个很好的管理、领导力培训机制，会对中层管理人员（如技术专家、项目经理、总监等）在一起进行一个为期2-3周的培训和互动，通过这个培训不仅仅提升了各人的管理能力，也增加了这些中层管理人员之间的熟悉度，让他们日后的工作中的合作很顺畅。