转载

微服务架构如何影响软件开发文化？

微服务，并不仅仅是一种代码构造方式。

微服务架构如何影响软件开发文化？

微服务概念一出现就引发了热烈讨论，很多文章都喜欢将其与整体式架构比较，乃至来自大型企业的用例等。然而，在说起微服务时，开发人员关注的往往是这场革命的技术意义，而非其象征的文化颠覆。虽然技术元素也很重要，但其中蕴含的文化变革更加值得重视。

我很幸运能够在 2014 年左右快速融入这场潮流，我也清楚地记得当时能够将陈旧的整体式应用迁移至新的、酷炫无比的微服务架构是多么令人兴奋。和很多朋友一样，我刚开始也只关注技术方面的影响——毕竟，当时正是革命性技术快速涌现的时期（例如，Docker 那时刚刚出现）。

然而，经过几年发展，尽管在技术层面发生了诸多变化，但我认为微服务对组织中软件开发方式产生的最大影响主要体现在代码归属权以及团队的职能定位上。

功能团队

虽然我们也可以在整体式架构下建立具有跨职能特性的团队，但组织通常会根据具体技术功能（例如前端、后端、系统管理员以及数据库开发等）进行团队拆分。因此，开发人员很少能够接触到生产环境，因此几乎不需要考虑生产与维护方面的问题。James Lewis 与 Martin Fowler 在最初定义微服务架构概念的文章中就强调过这一点。

微服务支持者倾向于消除这种固有模式，而更多将团队视为产品在整个生命周期当中的归属方。在这方面，比较典型的例子就是亚马逊提出的“谁构建、谁运行”原则，要求开发团队对生产环境中的软件负全部责任。

除此之外，将具有其他专业知识的人员引入团队（例如产品 / 营销），也使团队获得远超技术范畴的其他能力。团队将能够监控客户反馈、用户采用与商业价值，使团队对功能以及其中的各个层面负起完全责任。通过这样的新模式，团队将能够明确观察到他们的决策对于产品以及业务本身造成的影响。

代码所有权

在刚开始编程时，我曾投入数年时间研究游戏、桌面 /Web 应用程序以及网站等小型项目，把头脑中的想法转化为代码，给人一种莫名的愉悦感。然而，在开始从事软件开发职业之后，我发现真正的工作更像是流水线上的装配操作，而非艺术创作。

除了责任模糊外，在选择技术时，代码库与数据存储的集中特性同样有很多局限。关于框架、语言、设计模式以及数据库引擎选择方面的决策必须符合全局要求。简而言之，如果无法对所有要素进行整体把控，就很难获得理想的创造能力。

微服务架构还带来了小代码库概念。将原本的单一大存储库分散为几十个较小的存储库，能够确保特定存储库拥有明确的归属划分。很明显，代码所有权并不一定意味着必须由单个团队或者个人负责代码的整体维护。其他团队也可以根据需要提交 pull 请求（内部源）。但是，代码的所有者应当负责保障解决方案质量，并确保所有 pull 请求都符合代码标准以及 API 合约的要求。