我很幸运能够在 2014 年左右快速融入这场潮流，我也清楚地记得当时能够将陈旧的整体式应用迁移至新的、酷炫无比的微服务架构是多么令人兴奋。和很多朋友一样，我刚开始也只关注技术方面的影响——毕竟，当时正是革命性技术快速涌现的时期（例如，Docker 那时刚刚出现）。
然而，经过几年发展，尽管在技术层面发生了诸多变化，但我认为微服务对组织中软件开发方式产生的最大影响主要体现在代码归属权以及团队的职能定位上。
功能团队
虽然我们也可以在整体式架构下建立具有跨职能特性的团队，但组织通常会根据具体技术功能（例如前端、后端、系统管理员以及数据库开发等）进行团队拆分。因此，开发人员很少能够接触到生产环境，因此几乎不需要考虑生产与维护方面的问题。James Lewis 与 Martin Fowler 在最初定义微服务架构概念的文章中就强调过这一点。
微服务支持者倾向于消除这种固有模式，而更多将团队视为产品在整个生命周期当中的归属方。在这方面，比较典型的例子就是亚马逊提出的“谁构建、谁运行”原则，要求开发团队对生产环境中的软件负全部责任。
除此之外，将具有其他专业知识的人员引入团队（例如产品 / 营销），也使团队获得远超技术范畴的其他能力。团队将能够监控客户反馈、用户采用与商业价值，使团队对功能以及其中的各个层面负起完全责任。通过这样的新模式，团队将能够明确观察到他们的决策对于产品以及业务本身造成的影响。
代码所有权
在刚开始编程时，我曾投入数年时间研究游戏、桌面 /Web 应用程序以及网站等小型项目，把头脑中的想法转化为代码，给人一种莫名的愉悦感。然而，在开始从事软件开发职业之后，我发现真正的工作更像是流水线上的装配操作，而非艺术创作。
除了责任模糊外，在选择技术时，代码库与数据存储的集中特性同样有很多局限。关于框架、语言、设计模式以及数据库引擎选择方面的决策必须符合全局要求。简而言之，如果无法对所有要素进行整体把控，就很难获得理想的创造能力。
微服务架构还带来了小代码库概念。将原本的单一大存储库分散为几十个较小的存储库，能够确保特定存储库拥有明确的归属划分。很明显，代码所有权并不一定意味着必须由单个团队或者个人负责代码的整体维护。其他团队也可以根据需要提交 pull 请求（内部源）。但是，代码的所有者应当负责保障解决方案质量，并确保所有 pull 请求都符合代码标准以及 API 合约的要求。
总结
就我个人看来，拥有明确归属权的小型团队能够在日常开发工作中享受更多乐趣，并为开发人员提供足以激发创造力的自由空间。此外，使用小代码库会给人再次参与小型项目的感受，这能够在大型组织之内建立起初创精神。
请别误会，微服务也不是什么百试百灵的“银弹”。虽然面向微服务的架构有助于建立代码归属权与功能团队，但对场景也有着相当具体的要求。毕竟，这些功能在整体式代码库中也完全能够实现，只是需要辅以更多的组织参与投入。总结来讲，这场文化变革应有怎样的面貌、又是否适合，还得请各位开发人员自行判断。代码构造方式。
end：如果你觉得本文对你有帮助的话，记得关注点赞转发，你的支持就是我更新动力。
