人生苦短，不如养狗
作者：闲宇
公众号：Brucebat的伪技术鱼塘
一、技术 or 管理？
当谈到微服务时，我们到底是在谈论一个技术问题还是一个管理问题？
如果时间回到我刚接触微服务这样一个概念时，那么面对这个问题我一定会毫不犹豫的回答：这是一个技术问题。毕竟在刚毕业的时候，我的关注点更多的聚焦在技术实现上，对于事物的认知更多的是按照自底向上的方式来建立的。这就导致了提到某个概念或者理论时，脑海中浮现的更多是各种框架、中间件或者工具，而不是一个相对明确的定义描述。
但是随着在软件工程领域摸爬滚打的时间增长以及认知方式的改变，我愈发的觉得这样一个问题无法简单地将其归类为技术问题或管理问题。不过早些时候只是模糊地有这样一种感觉，真正意义上出现这样一个认知转变是在听了毕玄的一次分享之后。在这次分享当中他分享了一个让我当时非常震惊的事情：淘宝最初搞服务化（那个时候是服务化，真正意义上的微服务还要隔个几年）根本原因还是因为工程进度赶不上业务扩展的需求。由于有些代码会涉及多个业务多个团队，每每有业务调整需要涉及到这些代码时，排期就会成为一个非常大的难题，因为各个团队都要改动这个代码，谁先改、谁后改都需要协调排期，有些排期可能都要排到一年之后。但是业务是不会等人的，一年前业务可能是这样，谁也说不准一年后的业务是不是还是这样。所以分散治理成为迫在眉睫的事情。
当然，毕玄也提到了最初迫使他们进行架构变动的原因是业务扩展速度和软件迭代速度之间的矛盾不断激化，但是具体的理论依据其实当时并没有太多人想清楚，直到后来他们学习了谷歌关于微服务架构相关的分享和论文才发现：微服务架构最大的优势就在于便利了工程管理。每个业务团队围绕自己的业务开展开发工作，对于自己的服务有着独立的开发、维护和管理权限。
看到这里，可以发现在毕玄的分享当中更多的是在谈微服务架构在管理方面的优越性。那么微服务架构难道就是一个管理问题吗？当然不是，正如我上面说的，对于微服务架构我们不能简单地将其归为技术问题或管理问题。
二、再谈微服务架构
在Martin Fowler[1]和James Lewis[2]的Microservices : a definition of this new architectural term[3]文章中阐明了关于微服务的九种特性：
- 通过服务来实现独立自治的组件（Componentization via Services）
- 围绕业务能力构建（Organized around Business Capabilities）
- 产品化思维（Products not Projects）
- 轻量级通讯机制（Smart Endpoints and Dumb Pipes）
- 分散治理（Decentralized Governance）
- 数据去中心化（Decentralized Data Management）
- 基础设施自动化（Infrastructure Automation）
- 容错性设计（Design for Failure）
- 演进式设计（Evolutionary Design）
可以看到在这九种特性中关于团队管理相关的内容只有两条（围绕业务能力构建 、分散治理 ），如果硬要把产品化思维 算上也只有三条，其余的内容都是对技术方案的要求或者规范。但是我们并不能因此就认为管理的比重偏少，其实正是由于这三条关于管理的的要求或者规范才衍生出其余关于技术的要求或者规范。举个例子，正是因为需要分散治理，才会出现通过服务来实现自治的组件 、轻量级通讯机制 以及数据去中心化的技术要求。因为如果没有这些技术实现将无法完成团队对于服务独立、自治的需求。
所以说，微服务架构在管理方面和技术方面的要求或者规范两者是相辅相成、不可分离的，我们并不能单一地去看待这些问题。这其实也在一定程度上提醒了我们，即使并不身处管理岗，对于工程领域的问题也不能只是简单的自底向地上去考虑，很多时候也要学会自顶向下去思考。
参考资料：
[1] Martin Fowler: martinfowler.com/
[2] James Lewis: twitter.com/boicy
[3] Microservices : a definition of this new architectural term: martinfowler.com/articles/mi...