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

《Docker是微服务的天生好基友.doc》由会员上传分享，免费在线阅读，更多相关内容在应用文档-天天文库。

1、Docker是微服务的天生好基友？作者介绍李建业，前阿里巴巴员工（花名：李福），2002年本科毕业，之后一直从事软件开发，涉及办公自动化、电信网管/增值业务系统以及互联网；2009年12月加入淘宝的广告应用开发团队；从2011年底开始，关注软件研发本身，主要工作包括运维自动化系统和持续集成服务平台。前言微服务这个话题也算有段时间了，而且并不神秘，很多公司都在走这条路。有条推是这么解释微服务的，很有趣，引用一下：@arunguptaMicroservices=SOA-ESB-SOAP-Centralizedgovernance/persistence-Vendors+

2、REST/HTTP+CI/CD+DevOps+TruePolyglot+Containers+PaaS从微服务的角度看，Docker意味着什么？这两种技术之间应该是什么关系呢？我认为，Docker和微服务的关系应该是——好基友:-)。为什么这么说？且听下文分解。以下为本文的目录结构，请享用：1.微服务和单体架构2.应用开发3.组织结构4.系统变更碎片化5.运维相关设施好吧！我们正式开始。1.微服务和单体架构微服务的要点是“微”，与之对立的另一方是所谓的单体架构（monolith）。在团队实践中，这两种思路在不同的方面体现出了优劣差异：·应用开发§微服务便于支持多元技

3、术栈§单体架构有利于IDE和其它开发工具的配合支持·组织结构§微服务便于团队分裂，促进局部功能的业务深入§单体架构有利于开发者从全局角度理解和掌控功能·系统演化§微服务能够有助于用“碎片化”的方式推动系统演化，降低变更风险§单体架构便于”整体交付“，可以减少向下兼容的需要·运维相关设施§微服务增加了运维单元数量，对自动化运维比较依赖§单体架构可以手工运维，或者配合简单的自动化发布工具其实，微服务架构还有符合单一职责原则和便于接口依赖等好处，不过这些和Docker没什么关系，是单独在设计环节有价值的优点，所以这里就不提了。简单来说，微服务区别于单体架构的地方就在于“分

4、而治之”，即通过切分服务以明确模块或者功能边界。然而，仅有“分”是不行的，软件系统是一个整体，很多功能来自若干服务模块的配合，因此必然要有“合”的手段，这对矛盾会体现在多个方面，我们分别说明。2.应用开发之前已经讨论过语言技术栈多元化的趋势，但是，对于单体应用来说，多元化技术栈并不是值得推荐的实践方法，因为这里涉及到混合语言编程和不兼容的软件组织方式。实际上，现实中一些团队之所以没有办法拥抱多元化的技术栈，往往首先是因为他们的系统是一个或者几个“单体”应用，开发者已经习惯了原有的IDE和相关开发工具，引入其它技术带来的好处还不如制造的麻烦多。微服务则可以很好地避免这

5、种情况，它通过切分系统的方式为不同功能模块划定了清晰的边界，边界之间的通信方式很容易可以做到独立于某种技术栈，因此也就为纳入其它技术带来了空间。现实中也可以看到这样的例子，一些公司在初期会固定一个技术选型（比如facebook用php，google用python，阿里巴巴用java），而发展（或者收购）新的部门和组织以后，要么原有的应用被分裂，要么新的业务催生出新的独立应用，这时往往逐渐开始扩展技术选择。有拆就有合，不同技术栈的微服务之间，除了需要考虑通信机制，还要确保这些技术能够（以较低成本）变成一个系统——不同服务可以使用不同的语言框架，但是在线上应当成为一个整

6、体。于是我们会在发布中遇到“合”的困难，而这正是docker能解决的问题，具体讨论之前已经展开过，这里强调一下结论——docker将所有应用都标准化为可管理、可测试、易迁移的镜像/容器，因此为不同技术栈提供了整合管理的途径。在这种情况下，开发人员可以自由选择或者保持自己的常用工具，不必因为微服务的分裂产生过高的学习成本。3.组织结构说到团队和组织，不能绕开的一个话题就是“康威定律”(Conway’slaw)：软件系统的结构受制于其生产者组织的沟通结构。从这个角度看，微服务的拆分会对团队扩张带来帮助，这不难理解，因为系统拆分为若干微服务会促进这些微服务之间的边界更清晰

7、，我们知道，边界清晰等于在边界之间协作信息量少，如果按照微服务拆分团队，团队之间的协作成本将是比较低的。然而，“边界之间协作信息少”是有代价的。这代价就是团队的每个人对系统失去了整体视角和掌控能力，在这一点上，单体架构显然要好很多——每个开发者的开发环境都有完整的系统构建，所以很容易就可以获得对系统的整体印象和理解。这是微服务的短板，但是这个问题要分两种情况考虑：1.目前的技术发展使得在本机搭建一个完整的系统成本越来越高，即使不考虑微服务的影响，也会因为其它因素而推高这个代价。比如：一个普通的Web应用也许会购买push.io这样的手机端推送服务，因此期望本机能