本文讲的是利用微服务构建现代应用（二），【编者的话】本文是如何用微服构建现代应用的第二部分，介绍了如何用MongoDB中实现微服务，在迁移到微服务之前需要考虑的问题以及使用MongoDB构建微服务架构的客户案例。
在上一篇博文中，我介绍了微服务的背景知识及其优势。本文将介绍如何使用MongoDB构建微服务以及在实施微服务的项目中应该要注意的问题。
MongoDB如何实现微服务
企业要享受到微服务的好处需要一些基本的技术原则，其中最主要的是灵活的数据模型、冗余、自动化和可扩展性。灵活的数据模型：MongoDB的动态模式是处理微服务和持续交付需求的理想方式。当有新的功能上线需要修改数据模型时，无需修改所有的数据库记录，这对于关系数据库来讲可能需要花费数周。开发人员可以针对迅速变化的环境快速的迭代数据模型，因此提供了更好的灵活性和可以更快的将产品推向市场。
冗余：微服务的分布式特性造成了更多的失效点，例如更多的网络连接使得微服务的设计需要仔细的考虑冗余性。MongoDB非常适合这一点，因为它通过MongoDB副本提供了内建的冗余性。副本不仅仅提供了更好的错误恢复能力，也通过多数据中心的部署和在同一个数据库集群中隔离业务负载和分析报告负载的功能提供了更好的灾备能力。
监控和自动化：手动管理少量的服务并不困难，但是当服务的数量增加时，如果没有一个自动化的方式去管理这种复杂性的增加，生产力将会停滞。选择合适的监控和自动化工具对于保证DevOps团队的生产力是非常重要的，尤其是当环境变得复杂时。
MongoDB Ops Manager（同时也作为云服务提供）具有可视化、可定制的仪表盘和自动报警功能来帮助管理一个复杂的环境。
Ops Manager可以管理超过100个关键的数据库和系统的健康状况，包括操作计数器、CPU利用率、副本状态和任意节点的状态。这些度量被安全的送到Ops Manager进行处理和可视化。
图1：Ops Manager提供了MongoDB部署的实时和历史数据的可视化
通过Ops Manager的RESTful API跟已有的监控工具整合，以及通过内置的整合功能跟业界领先的APM（Application Performance Management）平台例如New Relic整合都是非常容易的。这种整合使得可以通过统一的管理界面MongoDB状态和应用基础设施中的其它部分。
可扩展性：通过扩展来满足新的业务需求是所有IT环境的必备能力，微服务也不例外。MongoDB提供了一整套可扩展的方案可以自动化的在多个节点之间分配和部署数据库，这可以非常容易的满足有动态以及高性能需求的IT基础设施。另外，通过auto-sharding功能（在需要时可以将部署分配到不同的地理域），MongoDB也非常适合在商用硬件上进行横向扩展。这比整体设计、纵向扩展的传统RDBMS来讲是有优势的，因为MongoDB是自动化和透明的。
为了获取更大的商业利益，很多组织正在将微服务迁移到云平台上。云平台的动态特性使得企业可以容易的进行纵向扩展或者收缩同时提供持续的可用性。
在迁移到微服务之前应该考虑的问题
虽然微服务有很多有点，但是它并不是适合所有人。在实施一个微服务项目之前有几个问题需要仔细考虑：监控：微服务的一个最重要的挑战是如何有效的监控整个系统。监控一两个服务是很容易的，但是如何有效的监控大量服务则会变得非常具有挑战性。不仅仅是有更多的服务器需要监控，同时也有更多的log文件需要分析，以及更大的可能性发生网络分裂。传统的方式是监控状态例如CPU，内存以及网络延迟等，这也是很重要的，但是企业用户也需要扩展监控能力去了解系统的度量和从一个长时间来看系统的运行情况。自动化监控流程可以帮助应付这些挑战和降低运营的开销。
更高的开发技能需求：微服务在分布式系统上运行，这意味着更高的复杂性。网络延迟、硬件失效、不可靠的网络、同步以及容错能力都需要细致的和适当的去处理。为了去处理这种增加的复杂性，开发人员需要很强的运营和产品背景。开发人员不再是简单的将开发好的程序交给运维团队即可，开发人员需要理解DevOps、测试和发布之间的关系来设计一个服务。在实现一个微服务架构之前，确定你的团队是否有能力处理这种复杂性是一件非常重要的事情。
更高的运营开销：对于某个整体性应用，它可能只是需要一个应用服务器集群和几个进程，但是一个微服务应用在增加了冗余之后可能需要50个服务和200个进程。运营和监控所有的这些进程会是一个令人生畏的任务。另外，服务需要通过持续交付线被测试和快速部署，这需要合适的工具和技能。
不正确的服务边界：在设计阶段就定义合适的服务边界是非常必要的。在从内部组件开始创建服务时，一个常见的问题就是没有很好的考虑服务边界。随着更多的功能被加入，有一种风险就是最终构建了一个巨大的分布式整体性应用。如果服务边界没有被正确的定义，将会增加成本，耦合的服务以及更高的测试复杂性。
MongoDB微服务部署
全世界成千上万的组织在使用MongoDB，包含几乎半数的财富100企业。很多企业在微服务架构中使用MongoDB来达到他们的业务和部署目标。Comparethemarket.com是英国一个领先的比价服务提供商，它使用了MongoDB作为其巨大的微服务环境背后的运营数据库。业务可用时间是非常关键的，MongoDB的分布式设计保证了SLA总是能被满足。Comparethemarket.com的部署包含了在AWS上的微服务。每一个微服务或者相关的逻辑分组都有专用的运行在Docker容器里的MongoDB副本，并部署在AWS的不同可用域以提高弹性和高可用性。MongoDB Ops Manager被用来提供运营自动化，这对快速上线新的功能至关重要：部署副本、提供持续的备份和执行无宕机时间的升级。
fuboTV是北美的一个流媒体服务提供商，提供全世界足球联赛的流媒体，fuboTV使用MongoDB作为其微服务架构的核心数据库。fuboTV的流媒体服务具有极端的突发性，在一个比赛开始前10分钟会是平常的流量的100多倍。为了处理业务增长和软件发布计划的需求，fuboTV将它的MongoDB数据库迁移到了Google云平台中被Kubernetes编排系统管理的Docker容器中。
图2：fuboTV 微服务架构
这给fuboTV待了带来了更高的灵活性、效率和上线时间。使用Kubernetes管理的容器，fuboTV可以将其所有的环境 – 开发、测试、QA和生产 – 部署到一个物理机集群中。Kubernetes调度器被用来精确的控制所有应用的资源分配，使得fuboTV可以最大化服务器利用率和减少成本。Kubernetes副本控制器可以在某个容器失败时自动的重新调度，从而实现容错和持续可用性。数据冗余是通过MongoDB的副本来实现的。这使得fuboTV在部署和升级应用时可以做到零宕机时间。
OTTO 是德国最大的时尚和生活品零售商，每天客流量有200万。OTTO的一个问题是并行的团队横跨多个业务领域（业务，项目管理，IT），他们会面对不同的问题但是都需要快速的提交结果。所有的团队都独立的选择了MongoDB作为最好的工具来快速和容易的获得结果。使用松耦合的团队，架构和运营，OTTO消除了部署和测试的瓶颈。团队可以快速的和迭代式的修改错误和支持持续交付。MongoDB是OTTO业务、IT和项目管理团队能够快速提交结果、提高开发的灵活性、允许团队无风险的创新的驱动力。
总结
微服务架构相比整体性架构有诸多的优点，但这并不意味着微服务没有挑战。合适的计划和应用的解耦合是能保证微服务架构可以达到你既定目的的前提。MongoDB非常适合微服务架构，MongoDB提供了灵活的模式、冗余、自动化和可扩展性。MongoDB和微服务的协同使用可以帮助组织有效的协调团队、更快的创新和在应用开发与交付的新时代中克服挑战。学习更多关于MongoDB和微服务的知识，请阅读白皮书Microservices: The Evolution of Building Modern Applications。
原文链接：Building Modern Applications with Microservices: Part 2（翻译：李光成）
======================================================
译者介绍
李光成，IBM中国研究院资深研究员，研究方向是云计算基础设施及技术。目前在做的是Docker资源隔离方面的研究项目。
原文发布时间为：2016-06-14
本文作者：liguangcheng
本文来自云栖社区合作伙伴DockerOne，了解相关信息可以关注DockerOne。
原文标题：利用微服务构建现代应用（二）