微服务架构如何影响软件开发文化？
极客时间编辑部
讲述：丁婵大小：2.03M时长：04:26
微服务概念一出现就引发了热烈讨论，很多文章都喜欢将其与整体式架构比较，乃至来自大型企业的用例等。然而，在说起微服务时，开发人员关注的往往是这场革命的技术意义，而非其象征的文化颠覆。虽然技术元素也很重要，但其中蕴含的文化变革更加值得重视。
近日，软件架构师阿尔伯特·科兹洛夫斯基（Albert Kozłowski）亲历了由整体式架构到微服务架构的迁移。他发现，经过几年发展，即使在技术层面发生了诸多变化，微服务也对组织中的软件开发方式产生了重大影响，其主要体现在代码归属权以及团队的职能定位上。以下为科兹洛夫斯基的观点。
首先是对于功能团队的影响，虽然我们也可以在整体式架构下建立具有跨职能特性的团队，但组织通常会根据具体技术功能，如前端、后端、系统管理员以及数据库开发等进行团队拆分。因此，开发人员很少能够接触到生产环境，所以几乎不需要考虑生产与维护方面的问题。James Lewis 与 Martin Fowler 在最初定义微服务架构概念的文章中就强调过这一点。
微服务支持者倾向于消除这种固有模式，而更多将团队视为产品在整个生命周期当中的归属方。在这方面，比较典型的例子就是亚马逊提出的“谁构建、谁运行”原则，要求开发团队对生产环境中的软件负全部责任。
除此之外，将具有其他专业知识的人员引入团队，也能使团队获得远超技术范畴的其他能力。团队将能够监控客户反馈、用户采用与商业价值，使团队对功能以及其中的各个层面负起完全责任。通过这样的新模式，团队将能够明确观察到他们的决策对于产品以及业务本身造成的影响。
其次，是对代码所有权的影响。在刚开始编程时，我曾投入数年时间研究游戏、桌面 /Web 应用程序以及网站等小型项目，把头脑中的想法转化为代码，给人一种莫名的愉悦感。然而，在开始从事软件开发职业之后，我发现真正的工作更像是流水线上的装配操作，而非艺术创作。
除了责任模糊外，在选择技术时，代码库与数据存储的集中特性同样有很多局限。关于框架、语言、设计模式以及数据库引擎选择方面的决策必须符合全局要求。简而言之，如果无法对所有要素进行整体把控，就很难获得理想的创造能力。
微服务架构还带来了小代码库概念。将原本的单一大存储库分散为几十个较小的存储库，能够确保特定存储库拥有明确的归属划分。很明显，代码所有权并不一定意味着必须由单个团队或者个人负责代码的整体维护。其他团队也可以根据需要提交 pull 请求（内部源）。但是，代码的所有者应当负责保障解决方案质量，并确保所有 pull 请求都符合代码标准以及 API 合约的要求。
总之，就我个人看来，拥有明确归属权的小型团队能够在日常开发工作中享受更多乐趣，并为开发人员提供足以激发创造力的自由空间。此外，使用小代码库会给人再次参与小型项目的感受，这能够在大型组织之内建立起初创精神。
请别误会，微服务也不是什么百试百灵的“银弹”。虽然面向微服务的架构有助于建立代码归属权与功能团队，但对场景也有着相当具体的要求。毕竟，这些功能在整体式代码库中也完全能够实现，只是需要辅以更多的组织参与投入。总结来讲，这场文化变革应有怎样的面貌、又是否适合，还得请各位开发人员自行判断。
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线笔记
复制
AI
- 深入了解
- 翻译
- 解释
- 总结
该免费文章来自《极客视点》，如需阅读全部文章，
请先领取课程
请先领取课程
免费领取
© 版权归极客邦科技所有，未经许可不得传播售卖。 页面已增加防盗追踪，如有侵权极客邦将依法追究其法律责任。
登录 后留言
精选留言
由作者筛选后的优质留言将会公开显示，欢迎踊跃留言。
收起评论