Docker是微服务的天生好基友.docVIP

- .. - -可修编. Docker是微效劳的天生好基友？ 作者介绍 建业，前阿里巴巴员工〔花名：福〕，2002年本科毕业，之后一直从事软件开发，涉及办公自动化、电信网管/增值业务系统以及互联网；2021年12月参加淘宝的广告应用开发团队；从2021年底开场，关注软件研发本身，主要工作包括运维自动化系统和持续集成效劳平台。 前言 微效劳这个话题也算有段时间了，而且并不神秘，很多公司都在走这条路。 有条推是这么解释微效劳的，很有趣，引用一下： arungupta Microservices = SOA -ESB -SOAP -Centralized governance/persistence -Vendors +REST/HTTP +CI/CD +DevOps +True Polyglot +Containers +PaaS 从微效劳的角度看，Docker意味着什么？这两种技术之间应该是什么关系呢？ 我认为，Docker和微效劳的关系应该是——好基友 :-)。为什么这么说？且听下文分解。以下为本文的目录构造，请享用： 微效劳和单体架构 应用开发 组织构造 系统变更碎片化 运维相关设施 好吧！我们正式开场。 1. 微效劳和单体架构 微效劳的要点是“微〞，与之对立的另一方是所谓的单体架构〔monolith〕。在团队实践中，这两种思路在不同的方面表达出了优劣差异： 应用开发 微效劳便于支持多元技术栈 单体架构有利于IDE和其它开发工具的配合支持 组织构造 微效劳便于团队分裂，促进局部功能的业务深入 单体架构有利于开发者从全局角度理解和掌控功能 系统演化 微效劳能够有助于用“碎片化〞的方式推动系统演化，降低变更风险 单体架构便于〞整体交付“，可以减少向下兼容的需要 运维相关设施 微效劳增加了运维单元数量，对自动化运维比拟依赖 单体架构可以手工运维，或者配合简单的自动化发布工具 其实，微效劳架构还有符合单一职责原那么和便于接口依赖等好处，不过这些和Docker没什么关系，是单独在设计环节有价值的优点，所以这里就不提了。 简单来说，微效劳区别于单体架构的地方就在于“分而治之〞，即通过切分效劳以明确模块或者功能边界。 然而，仅有“分〞是不行的，软件系统是一个整体，很多功能来自假设干效劳模块的配合，因此必然要有“合〞的手段，这对矛盾会表达在多个方面，我们分别说明。 2. 应用开发 之前已经讨论过语言技术栈多元化的趋势，但是，对于单体应用来说，多元化技术栈并不是值得推荐的实践方法，因为这里涉及到混合语言编程和不兼容的软件组织方式。 实际上，现实中一些团队之所以没有方法拥抱多元化的技术栈，往往首先是因为他们的系统是一个或者几个“单体〞应用，开发者已经习惯了原有的IDE和相关开发工具，引入其它技术带来的好处还不如制造的麻烦多。 微效劳那么可以很好地防止这种情况，它通过切分系统的方式为不同功能模块划定了清晰的边界，边界之间的通信方式很容易可以做到独立于某种技术栈，因此也就为纳入其它技术带来了空间。 现实中也可以看到这样的例子，一些公司在初期会固定一个技术选型〔比方facebook用php，google用python，阿里巴巴用java〕，而开展〔或者收购〕新的部门和组织以后，要么原有的应用被分裂，要么新的业务催生出新的独立应用，这时往往逐渐开场扩展技术选择。 有拆就有合，不同技术栈的微效劳之间，除了需要考虑通信机制，还要确保这些技术能够〔以较低本钱〕变成一个系统——不同效劳可以使用不同的语言框架，但是在线上应当成为一个整体。 于是我们会在发布中遇到“合〞的困难，而这正是docker能解决的问题，具体讨论之前已经展开过，这里强调一下结论——docker将所有应用都标准化为可管理、可测试、易迁移的镜像/容器，因此为不同技术栈提供了整合管理的途径。 在这种情况下，开发人员可以自由选择或者保持自己的常用工具，不必因为微效劳的分裂产生过高的学习本钱。 3. 组织构造 说到团队和组织，不能绕开的一个话题就是“康威定律〞(Conway’s law)： 软件系统的构造受制于其生产者组织的沟通构造。 从这个角度看，微效劳的拆分会对团队扩带来帮助，这不难理解，因为系统拆分为假设干微效劳会促进这些微效劳之间的边界更清晰，我们知道，边界清晰等于在边界之间协作信息量少，如果按照微效劳拆分团队，团队之间的协作本钱将是比拟低的。 然而，“边界之间协作信息少〞是有代价的。这代价就是团队的每个人对系统失去了整体视角和掌控能力，在这一点上，单体架构显然要好很多——每个开发者的开发环境都有完整的系