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

Docker是微服务的天生好基友？作者介绍李建业，前阿里巴巴员工（花名：李福），2002年本科毕业，之后一直从事软件开发，涉及办公自动化、电信网管/增值业务系统以及互联网；2009年12月加入淘宝的广告应用开发团队；从2011年底开始，关注软件研发本身，主要工作包括运维自动化系统和持续集成服务平台。前言微服务这个话题也算有段时间了，而且并不神秘，很多公司都在走这条路。有条推是这么解释微服务的，很有趣，引用一下：@arunguptaMicroservices = 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)：软件系统的结构受制于其生产者组织的沟通结构。从这个角度看，微服务的拆分会对团队扩张带来帮助，这不难理解，因为系统拆分为若干微服务会促进这些微服务之间的边界更清晰，我们知道，边界清晰等于在边界之间协作信息量少，如果按照微服务拆分团队，团队之间的协作成本将是比较低的。然而，“边界之间协作信息少”是有代价的。这代价就是团队的每个人对系统失去了整体视角和掌控能力，在这一点上，单体架构显然要好很多——每个开发者的开发环境都有完整的系统构建，所以很容易就可以获得对系统的整体印象和理解。这是微服务的短板，但是这个问题要分两种情况考虑：目前的技术发展使得在本机搭建一个完整的系统成本越来越高，即使不考虑微服务的影响，也会因为其它因素而推高这个代价。比如：一个普通的Web应用也许会购买push.io这样的手机端推送服务，因此期望本机能够重现所有