您所在的位置： &
【技术分享】基于容器云的微服务架构实践
【技术分享】基于容器云的微服务架构实践
近年来，微服务架构及容器技术备受关注，在各类文章、演讲、博客中频频亮相，成为业界最热门的话题。微服务以一种全新的架构设计模式，牵动了互联网应用从设计到运维整个流程方法论的变革。 ‌‌而以Docker为代表的容器技术则为微服务理念提供了匹配的实现机制，进而实质性的改变了新一代应用开发和发布的方式。
微服务架构的诞生和容器技术的流行，几乎是同时发生的，这并非偶然，而是互联网时代倒逼传统技术和架构而产生的变革，而以Docker为代表的容器技术则为微服务理念提供了匹配的实现机制，本文作者从什么是微服务切入，详细的介绍了微服务架构的优势，最后从自身实践出发，给出了微服务架构的云端实践。
近年来，微服务架构及容器技术备受关注，在各类文章、演讲、博客中频频亮相，成为业界最热门的话题。在时尚的词汇和热情满满的讨论背后，人们开始严肃的重新思考互联网时代服务的架构以及应用开发、运维的方法。微服务以一种全新的架构设计模式，牵动了互联网应用从设计到运维整个流程方法论的变革。 &&而以Docker为代表的容器技术则为微服务理念提供了匹配的实现机制，进而实质性的改变了新一代应用开发和发布的方式。
什么是微服务架构?
微服务架构(Microservices Architecture)是一种架构风格(Architectural Style)和设计模式，提倡将应用分割成一系列细小的服务，每个服务专注于单一业务功能，运行于独立的进程中，服务之间边界清晰，采用轻量级通信机制(如HTTP/REST)相互沟通、配合来实现完整的应用，满足业务和用户的需求。
微服务作为架构模式的变革，其诞生绝非偶然。它是当传统服务架构在互联网时代遭遇挑战时，人们对于架构模式，开发和运维方法论的一种反思。所以，在深入探讨微服务架构之前，我们先回顾一下更为普遍的传统服务架构。
传统&单块架构&：
在过去的10多年中，甚至是微服务日趋流行的当下，绝大多数应用采用的仍是我们更为熟悉的传统架构，称之为 &单块架构(Monolithic Architecture)&模式。此类架构系统通常以技术分层，例如最常见的&分层架构&中的表现层、业务逻辑层、数据层。而业务逻辑则可根据更具体的业务职责、功能进行模块化，形成逻辑组件。这里需要提一下的是，&分层架构&虽然有逻辑上的模块和组件，但在物理部署架构层面仍是一个&单块&，通常作为一个整体编译、打包、部署、运维。&单块架构&便是从物理部署角度，对于包括&分层架构&在内的应用架构模式的一种定义。
&分层架构&是软件架构体系中的经典模式，也是长时间来应用架构实际上的标准。而单块架构也有其一定优势，体现为：
便于开发：大量常用的集成开发环境(IDE)和编程框架(如Rails，Django)都是围绕传统架构下单块应用设计的。这些工具为开发者提供了方便和熟悉的开发、调试体验;
便于测试：由于整个应用包含在一个进程中，在常用工具的配合下应用可以很容易在开发、测试环境中启动。然后采用UI自动化工具(如Selenium)便可简单实现End-to-End测试;
便于部署：多数编程语言和框架都有特定的应用打包格式。部署只需将单一软件包复制到运行环境。而这一过程也可通过现有工具实现自动化。
由于这些优点，在项目初期，单块架构有一定的吸引力。开发者可以通过工具、框架快速生成应用原型，而不必花大量精力在服务分解和分布式架构设计上。但随着业务的扩张和功能的累积，原本简单的应用体积会迅速变大，此时单块架构很难适应快速变更的需求，由于架构层面的局限性，这类应用会面临多重挑战。
开发效率低：随着应用复杂度的增加，越来越少开发人员对应用能有全局性的深度理解。新功能开发和缺陷修复难度呈几何性增加。代码修改的正确性无法保障。而庞大的代码库需要更庞大的开发团队来维护，无形中又增添了管理、沟通和协调的成本。另外，新加入的团队成员需要花费大量的时间和精力来熟悉一个复杂的代码库。
交付周期长：在单一进程的单块架构下，任何微小的改动都需要重新编译、集成、测试和部署整个应用。随着应用体积的增大，交付流程和反馈周期都会相应变长，应用发布的代价也随之增加。于是应用交付周期变缓，交付间隙积累的代码变动增加，从而对于下次交付产生更大的压力，形成恶性循环。
技术转型难：单一进程、单块架构意味着中心化的技术选型。比如，应用的不同逻辑组建通常需要采用相对统一的编程语言、框架和技术栈。这些在项目初始阶段便已定型。之后，即便是应用中全新的逻辑组件，也很难采用不同的技术栈。而当应用达到一定规模后，全局化的技术栈更新会面临很高的风险。所以，单块架构应用一旦定型，就很难再享受行业技术变更、发展所带来的红利。
由于这些结构性、系统性问题的存在，单块架构下的应用越来越难适应互联网时代快速变更的市场需求。微服务便是从架构层面出发，推动传统应用开发、运维方式的变革，从而帮助企业快速响应市场需求、快速迭代、快速交付，在互联网时代保持竞争力。
微服务架构的优势：
在微服务架构下，我们将原本单一的应用按照功能边界分解成一系列独立、专注的微服务。每个微服务对应传统应用中的一个组件，但是可以独立编译、部署和扩展。相对单块架构，微服务具备以下优势：
复杂度可控：在将应用分解的同时，规避了原本复杂度无止境的积累。每一个微服务专注于单一功能，并通过定义良好的接口清晰表述服务边界。由于体积小、复杂度低，每个微服务可由一个小规模开发团队完全掌控，易于保持高可维护性和开发效率;
独立部署：由于微服务具备独立的运行进程，所以每个微服务也可以独立部署。当某个微服务发生变更时无需编译、部署整个应用。由微服务组成的应用相当于具备一系列可并行的发布流程，使得发布更加高效，同时降低对生产环境所造成的风险，最终缩短应用交付周期。
技术选型灵活：微服务架构下，技术选型是去中心化的。每个团队可以根据自身服务的需求和行业发展的现状，自由选择最适合的技术栈。由于每个微服务相对简单，当需要对技术栈进行升级时所面临的风险较低，甚至完全重构一个微服务也是可行的。
容错：当某一组建发生故障时，在单一进程的传统架构下，故障很有可能在进程内扩散，形成应用全局性的不可用。在微服务架构下，故障会被隔离在单个服务中。若设计良好，其他服务可通过重试、平稳退化等机制实现应用层面的容错。
扩展：单块架构应用也可以实现横向扩展，就是将整个应用完整的复制到不同的节点。当应用的不同组件在扩展需求上存在差异时，微服务架构便体现出其灵活性，因为每个服务可以根据实际需求独立进行扩展。
微服务架构的云端实践
虽然微服务架构带来了诸多优势，但必须承认，构建，部署，维护分布式的微服务系统并不容易。而容器所提供的轻量级、面向应用的虚拟化运行环境为微服务提供了理想的载体。同样，基于容器技术的云服务将极大的简化容器化微服务创建、集成、部署、运维的整个流程，从而推动微服务在云端的大规模实践。以下将以灵雀云为例，来说明各个流程的实践：
灵雀云的镜像构建和持续集成服务帮助用户将独立、可复用的微服务打包，转化为随时可以部署的容器镜像。假设用户的微服务程序，存储于GitHub 等代码托管服务中，用户可以将这个代码仓库构建成容器镜像，并保存在灵雀云的镜像仓库中，用户可以将这个微服务一键部署到我们的容器云平台。同时，灵雀云提供了持续集成的功能，用户可以选择是否性使用。每当微服务的代码有变化时，就构建一个新的容器镜像，以便以后部署使用。
灵雀云不仅在平台的镜像仓库中汇集了大量来自Docker官方和社区的优质镜像，也支持平台以外的任意镜像源。用户可以自由组合、复用数以万计的容器化微服务，像搭积木一样轻松集成应用。比如，用户需要一个通用的MySQL数据库服务，他无需构建镜像，可以直接在镜像社区中选择适合的数据库服务镜像，并与其微服务链接起来。
微服务由于组件数量众多，云端部署成为实践上的一个难点。灵雀云以容器为应用发布的载体，用户不必指定传统部署方式中繁琐的步骤，只需提供容器镜像和简单的容器配置，平台会将整个部署流程自动化。
灵雀云还与docker-compose兼容，实现对于由多个微服务容器组成的完整应用的一键部署。
微服务由于独立进程众多，部署后的运维、管理成为实践上的另一个难点。灵雀云完全屏蔽底层云主机和基础架构运维，让用户专注于应用。同时，灵雀云通过容器编排、自动修复、自动扩展、监控日志等高级应用生命周期服务，实现容器化微服务的智能托管，进一步帮助用户降低运维成本和难度。
微服务架构下各组件之间的沟通、协调对网络有较高要求，尤其在云端实践中，各个微服务组件的物理位置是动态的，且不受应用控制。灵雀云提供完整的容器网络解决方案，支持负载均衡、服务发现、跨主机关联，以及应用安全内网来确保微服务对内、对外网络的可用性及安全性。
1.首先，要实现服务的高可用性，负载均衡器是必不可少的，灵雀云支持基于传输层和应用层的负载均衡，以满足用户不同需求。
2.负载均衡也可以实现服务发现，云端部署服务时，各个组件部署的物理位置是有可能发生变化的。在灵雀云，当用户创建一个微服务的时候，不论这个服务是停止状态还是运行状态，我们都会为服务创建负载均衡器和一个域名，这样其他服务就可以通过这个域名访问该服务。即使服务中的容器实例被迁移，系统也会在它重新启动后，将它挂载回原来的负载均衡器。
3.跨主机关联，是指微服务的容器实例会被部署在不同的云主机上，但会被关联到该服务的负载均衡器上，以服务来自内网或外网的请求。
4.内部服务地址，对于很多微服务应用来说，这是个很重要的功能，比如在一个应用中，一个微服务需要访问一个cache服务器(比如memcached)，但是出于安全的考虑，不希望外部请求访问到这个cache服务器，就可以使用灵雀云的内部服务地址。系统同样会创建负载均衡，以及域名，但是这个域名只供该用户的其他服务访问，外部应用，或其他用户服务是无法访问的。
5.专属IP是灵雀云最近新增的一个功能，有些用户由于特殊需求，不希望和其他用户共享IP，就可以申请一个专属IP，并绑定在自己的应用上，以获得更好的隔离性。
微服务提倡多元化持久性(Polyglot Persistence)，应用内的每个微服务可根据实际需求选择最合适的数据服务。微服务一般分两类，无状态服务和有状态服务，无状态服务比如应用服务器，他们通常是不保存数据的，方便横向的扩展。有状态服务需要存储数据，比如数据库服务，缓存服务。
Docker的特性，决定了容器本身的数据并不是持久化的，需要通过挂载Volume来实现数据的存储。灵雀云将持久性云存储抽象成数据卷，可以直接挂载在容器上，并在容器重启、迁移中自动重新挂载。可支持任意容器化数据服务，供微服务应用集成。同时，支持对微服务数据的备份，恢复，和下载，可以利用备份随时恢复数据。
微服务架构的诞生和容器技术的流行，几乎是同时发生的，这并不是偶然。这是互联网时代倒逼传统技术和架构而产生的变革，最前线的开发者和他们所在的互联网企业最先感受到了这场变革。灵雀云希望与开发者一起共同引领这场变革，帮助互联网企业真正专注于自身的核心业务，并在技术和架构上保持领先。
作者简介：
陈恺，2015年正式加盟灵雀云，任首席技术官。携其十数年大规模、企业级分布式系统/云平台研发经验，打造基于容器技术、面向开发者的云计算平台。加入云雀科技之前，2004年在微软从事Windows操作系统内核(Kernel)的研发，2010年出任微软云平台Windows Azure首席架构师/软件开发部经理，专注于云计算/分布式系统的研发，组建、带领团队开发Azure最核心的中控系统(Fabric Controller)，管理并支撑整个云平台后端，承载千万级规模应用。
&【编辑推荐】【责任编辑： TEL：（010）】
关于&&&&的更多文章
本书介绍最新的VMware虚拟化与云计算软件VMware Workstation 9、
180天的Windows Server 2012试用版下载（标准版或数据中心版）
讲师： 867人学习过讲师： 4324人学习过讲师： 3599人学习过
简单来说，云存储就是将储存资源放到云上供人存取的一
OpenStack是一个美国国家航空航天局和Rackspace合作研
日，以“变革的力量”为主题的2014东软解
SQL Server 2005微软官方权威参考手册。
是Inside Microsoft SQL Server 2005系列书中的第一本，SQL Server类的顶尖之作。
51CTO旗下网站微服务架构入门，一些具有代表性的问题 - 博客频道 - CSDN.NET
xiaoman的博客
分类：微服务
昨天收到一封合作客户的邮件，提了一些关于微服务的问题，要求解答。
看了一下，觉得这些问题比较有代表性，很多准备开始做微服务架构的企业或个人都有类似的疑问，因此针对这些问题写点东西，希望对一些微服务入门者有所帮助。
（1）如何将当前的产品拆解为微服务（组件），每个微服务应包括哪些元素？
要把单体式应用拆分成微服务组件，并没有一个具像的标准说这个组件应该包括哪些元素。而是需要从业务的角度去分析：某一些功能是否逻辑相对独立、可复用性高、使用频度高等等，根据这些因素判断是否该拆分出来作为一个微服务组件。
微服务设计强调服务的独立性：不同微服务使用不同的数据，与外部交互通过消息或API而不是耦合的依赖关系;此外，微服务组件的设计需要把握“微”的度，所以不宜在基础的功能上做过多的堆叠，否则每个微服务组件可能又变成了大的单体应用。
具体来说，微服务设计需要可从以下几个方面着手：
实现前后端分离，可把代码分为前端、服务层、底层代码；
根据业务逻辑及技术层面的系统架构综合考虑，抽取模块成服务;
打造服务间的轻量通信基础组件及协议，例如REST或消息队列
（2）如何搭建合理的微服务总线和通信机制？
这个问题提到的所谓的微服务总线实际上主要包括两方面的功能：服务发现和服务调用。
例如阿里开源的Dubbo框架就是一种微服务框架，它借助Zookeeper等多种注册中心实现对Provider服务的注册，并且提供服务发现功能。
Dubbo支持Hessian、WebService、Thrift等方式的RPC远程服务调用，此外当当扩展的dubbox还支持REST API的服务调用方式。
事实上更地道的微服务架构会采用基于异步通信的调用。在异步通信中，各服务间彼此依赖，但不会因相互等待结果而导致响应速度缓慢。因此，如果一项服务发生故障，其不会影响到其它服务，瓶颈与单点故障问题也将不复存在。
（3）如何保障负载均衡和微服务系统的整体可靠性？
参考Dubbo提供的ConfigServer的原理，就可知道如何保证微服务系统的负载均衡和整体的可靠性问题了。如果你的系统是Java应用，就可以使用现成的Dubbo，当然你也可以支持根据这个基本原理写自己的微服务支持框架。
Dubbo的配置中心和每个Server/Client之间会作一个实时的心跳检测，收集并更新每个Server提供的服务的信息，每个Client的信息。
每个Server启动时，主动与ConfigServer建立连接，并将自己的IP，提供的服务名称，端口等信息直接发送给ConfigServer，ConfigServer会更新服务列表。
Client在使用服务的时候根据服务名称去ConfigServer中获取服务提供者信息，后面就可以直接调用服务了。当有多个服务提供者的时候，Client根据一定的规则来进行负载均衡，如轮询，随机，按权重等。一旦Client使用的服务它对应的服务提供者有变化，ConfigServer就会把最新的服务提供者列表推送给Client，Client重新建立连接。
（4）如何管理服务组件的版本，实现快速部署和无缝升级？
微服务架构下的应用由若干个微服务组件组成，与单体式应用相比其服务组件的版本管理及部署、升级都会变得复杂了，如果全靠手工去做，必然效率底下。
一套完善的开发管理规范，包括开发设计规范、分支管理规范、持续集成规范，再利用Docker容器的天然的特性：“版本控制、可移植性、隔离性”就可以实现组件的版本管理。实质上基于在支持DevOps完整流程的容器云平台，即可实现整个开发过程及交付中的持续集成、快速部署、灰度发布及无缝升级。
（5）如何搭建配套的服务控制台和管理系统？
在容器云平台上搭建你的开发、测试及运行环境可实现容器化的持续集成持续部署，即以容器的形式发布应用。平台可以提供容器服务的监控及管理的全套功能，无需自己搭建服务控制台和管理系统。
排名：千里之外
（2）（1）孙宏亮：微服务架构下Docker怎么玩？
　作者: 张苗苗　编辑:
　　【IT168 】2015SACC—中国系统第三天，在经历了前两日阴雨连绵、地铁“宕机”等小插曲之后，在这个周六的早上，架构师们仍旧没有放弃追求技术的热情，各个专场的会场内，坐满了前来听会学习的嘉宾。在新云南皇冠酒店的二楼，“容器技术进展”专场，精彩仍旧继续，场面同样火爆 。来自DaoCloud的工程师&初创团队成员孙宏亮，带来了主题为《微服务架构下应用docker化实践》的分享，解析了开发运维环节，容器怎样为IT带来便利，并介绍了其自身Docker化实践的相关心得。▲活动现场　　▲DaoCloud的工程师&初创团队成员孙宏亮　　什么是微服务架构?　　当下，越来越多的新业务需求被不断提出，企业的开发运维团队面临着巨大的挑战。如何保证新业务及时上线?如何保持新产品的快速迭代?尤其是互联网行业，在保证应用稳定运行的情况下，仍旧要不断提高用户体验，因为一旦体验不好，带来的用户大量流失，是企业业务不可承受之痛。于是，开发团队不断尝试，寻求更好的研发流程，尽可能的缩短产品研发周期，加速产品迭代。最终在业务压力的驱使下，微服务架构理念逐步走进开发人员的视野。　　微服务架构不算创新理念，有业内专家曾表示，早前，企业级开发团队的SOA就是微服务架构的前身。简单来说，微服务架构其实是一种软件架构的模式，在这种理念的指导下，传统应用在开发过程中，被解耦成许多微小的应用，变成小而专的应用。“把系统拆分成小的系统之后，就简化了开发的流程，缩短了开发周期，提升了运维的效率。”孙宏亮表示。▲微服务的扩展立方模型　　“扩展立方模型”是指微服务架构的在拆分时包括三个维度，如上图所示，X轴表示水平副本，通过副本进行扩展;y轴表示功能解耦，通过分解功能，在不同模块之间的扩展;Z轴是数据分区，一个系统会有一些业务和数据，微服务架构可以通过数据分区的形式进行扩展。　　什么是Docker?　　“Docker是一个开源的应用容器引擎，让开发者可以打包他们的应用以及依赖包到一个可移植的容器中，然后发布到任何流行的 Linux 机器上，也可以实现虚拟化。 容器是完全使用沙箱机制，相互之间不会有任何接口(类似 iPhone 的 app)。几乎没有性能开销，可以很容易地在机器和中运行。最重要的是,他们不依赖于任何语言、框架包括系统。”这是百度百科的官方解释。　　孙宏亮将其归纳为，docker作为容器技术，可以有效的分配和管理物理资源，包括、、等。“开发人员可以在物理机上部署一批容器，物理机与物理机，物理机与虚拟机，虚拟机与虚拟机之间都是相互资源的。这种松耦合的架构很好的帮助企业实现微服务架构。”孙宏亮解释。“我认为Docker包含两大核心技术：一方面是容器技术，可以进行物理资源的有效分配与管理，并实现资源，从这个角度看来，容器跟虚拟机的理念比较类似。另一方面是镜像技术。打破了‘代码即应用’的观念，从系统环境开始，自底至上打包应用的镜像技术。Docker解决了软件的环境一致性问题，使得软件的分发与交付异常便捷。”　　通过Docker技术，使得开发人员(Dev)，可以开发简单有效的模块，将精力专注于主营业务，不再浪费主要精力在异常复杂的应用开发。针对运维人员(Ops)，通过Docker很好的管理硬件设施，很好的做到资源隔离，得到更好地监控和反馈。“我一直觉得，运维人员不应该专注应用执行逻辑，不应该将精力放在应用的执行上，Docker的出现充分帮助运维人员减负。”　　▲从扩展立方模型看微服务与Docker化　　Docker化实践　　据笔者了解，目前，大部分企业的开发者对于容器的概念与价值已经不陌生，但是苦于没有好的方式方法，将容器技术很好的应用到自己的开发运维流程中，孙宏亮作为国内首批实践Docker技术的工程师，结合自身的经验，为现场的嘉宾带来了他认为的，使用Docker的最佳实践。　　他认为，Docker实践的本质是进程隔离与资源管理。具体来说，分为三个步骤，首先，需要定义一个Dockerfile，Dockerfile定义了进程需要的一切东西。Dockerfile涉及的内容包括执行代码或者是文件、环境变量、依赖包、运行时环境、动态链接库、的发行版、服务进程和内核进程(当应用进程需要和系统服务和内核进程打交道，这时需要考虑如何设计namespace的权限控制)等等;第二个方面是Docker镜像，在用Dockerfile定义一个文件之后，docker build时会产生一个Docker镜像，当运行 Docker镜像时，会真正开始提供服务;第三点是Docker容器，容器是直接提供服务的，关于容器的“单进程模式”，需要注意一点，容器里面有一个非常重要的进程——init进程，它负责管理容器内部的所有进程，一旦该进程出现故障，系统会负责给容器内所有其他进程发送一个kill信号，随即容器退出运行。在实践时需要保证init进程不能经常出问题，当然也可以通过Docker层面，设置一些restart policy等策略，来保证容器能够成功恢复，不过如果容器内部已经有状态时，同样也会出现一些问题。“这样的交付形式，依托Docker妙计部署，功能解耦等优势，大大缓解了运维人员的工作压力。”　　▲Docker化实践的三个步骤　　最后，孙宏亮介绍了遗留系统如何无差异地Docker化，并介绍了传统应用Docker化的两个关键——日志管理和配置管理。事实上，Docker里面也有一个init进程，Docker init进程跟宿主机上的init进程有很大的差异，Docker的init进程是完成资源的初始化，然后把决策完全交给用户指定的进程。另外，传统模式下，很多应用很多组件都会调用服务进程来完成特殊的需求，比如，如果说某一个组件是需要完成日志的，会需要syslog的服务来完成这些目标，可不可以把这些放到容器中呢?如果把它们放到容器中，容器的逻辑就变得比较复杂。▲Docker化实践——syslog日志管理进程的Docker化　　孙宏亮表示，目前其所在的企业DaoCloud，因为是创业公司，没有旧有的系统架构，其自身的平台也是基于DaoCloud研发和运维的，用孙宏亮的话说，我们DaoCloud基于DaoCloud是基于开发DaoCloud。“现在我们的研发过程发布出去的所有组件都是镜像，Docker的轻量便捷，使得我们无论从业务研发，还是产品输出的速度与质量优势都十分明显。”
大学生分期购物销量榜
IT168企业级微服务架构快速指南 -解道Jdon
& & & &&& & &
　　1. 什么是软件架构?
　　软件架构是一个包含各种组织的系统组织，这些组件包括 Web服务器, 应用服务器, 数据库,存储, 通讯层), 它们彼此或和环境存在关系。
　　2.什么是微服务架构?
　　微服务是指开发一个单个 小型的但有业务功能的服务，每个服务都有自己的处理和轻量通讯机制，可以部署在单个或多个服务器上。
　　微服务也指一种种松耦合的、有一定的有界上下文的面向服务架构。也就是说，如果每个服务都要同时修改，那么它们就不是微服务，因为它们紧耦合在一起；如果你需要掌握一个服务太多的上下文场景使用条件，那么它就是一个有上下文边界的服务，这个定义来自。
　　3. 微服务优点是什么？
每个微服务都很小，这样能聚焦一个指定的业务功能或业务需求。
微服务能够被小团队单独开发，这个小团队是2到5人的开发人员组成。
微服务是松耦合的，是有功能意义的服务，无论是在开发阶段或部署阶段都是独立的。
微服务能使用不同的语言开发。
微服务允许容易且灵活的方式集成自动部署，通过持续集成工具，如Jenkins, Hudson, bamboo 。
一个团队的新成员能够更快投入生产。
微服务易于被一个开发人员理解，修改和维护，这样小团队能够更关注自己的工作成果。无需通过合作才能体现价值。
微服务允许你利用融合最新技术。
微服务只是业务逻辑的代码，不会和HTML,CSS 或其他界面组件混合。
微服务能够即时被要求扩展。
微服务能部署中低端配置的服务器上。
易于和第三方集成。
每个微服务都有自己的存储能力，可以有自己的数据库。也可以有统一数据库。
　　4. 微服务架构的缺点是什么?
微服务架构可能带来过多的操作。
需要DevOps技巧 (http://en.wikipedia.org/wiki/DevOps).
可能双倍的努力。
分布式系统可能复杂难以管理。
因为分布部署跟踪问题难。
当服务数量增加，管理复杂性增加。
　　5. 微服务适合哪种情况?
　　当你需要支持桌面 web 移动 智能电视 可穿戴时都是可以的，甚至将来你可能不知道但需要支持的某种环境。
　　6. 哪个公司或产品使用微服务架构?
　　大部分大型网站系统如Twitter, Netflix, Amazon 和 eBay都已经从传统整体型架构monolithic architecture迁移到微服务架构
　　7. 微服务之间是如何独立通讯的？
　　这依赖需求，通过使用HTTP/REST，数据格式使用JSON 或 Protobuf(Binary protocol)，通讯协议是自由的。
　　8. 为什么现在每个人都在谈论微服务？
　　自从SOA面试15年来，随着RESTful web服务和JSON数据交换格式流行，简单快速建立一个可连接的服务已经越来越方便了。
开发方式影响
　　随着持续交付概念推广以及Docker容器普及，微服务将这两种理念和技术结合起来，形成新的微服务+API + 平台的开发模式，提出了容器化微服务的持续交付概念。
　　下图传统Monolithic的DevOps开发队伍方式：
　　这种整体型架构要求产品队伍横跨产品管理 Dev开发 QA DBA 以及系统运营管理，而微服务架构引入以后，如下图：
　　微服务促进了DevOps方式的重组，将一个大臃肿的整体产品开发队伍切分为根据不同微服务的划分的产品队伍，以及一个大的整体的平台队伍负责运营管理，两者之间通过API交互，做到了松耦合隔绝。
　　由于Docker引入，不同的微服务可以使用不同的技术架构，比如Node.js Java Ruby Python等等，这些单个的服务都可以独立完成交付生命周期，如下：
微服务案例
　　Netflix的微服务架构如下，着重全球分发 高可扩展性和可用性：
　　Twitter的微服务架构，注重高效的可扩展的数据中心：
| 网站地图 | 设为首页}