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