简介
随着互联网公司在高度竞争性的市场中需要快速灵活的复制其开发环境，应用程序的开发正变得越来越复杂。庞大并且整体的应用程序在过去是企业的竞争力，但是在新的情境中却使得快速部署新的服务成为了问题。而分散的和分布式开发会带来组织架构上的问题。基于此，用户的要求比过去任何时候更高 – 企业需要有效的扩展并且监控已部署的系统以确保高性能和一致的用户体验。当然，这一切都需要在服务不中断的情况下完成。
上述的这些趋势对软件架构模式提出了新的要求以使其能处理在当前时代下的需求。整体化的架构是一种传统的方式，但是存在诸多问题：不易于扩展，大的代码库难于维护，升级过程有很大的风险，前置的准备成本等，所有这些迫使企业寻求新的方法。
在过去几年，微服务的概念进入了人们的视野。由于其在提供模块化、可扩展、高可用的应用方面的能力以及促进组织架构融合方面的优势使得它迅速的被业界所接受。
整体化架构
在微服务之前，一个通用的软件设计模式是使用整体化架构。在这种模式下，应用程序在开发、测试、打包和部署阶段都是作为一个整体存在。代码库被整体编译，应用程序被作为一个实体部署。扩展需要将应用程序的二进制文件和依赖的库文件拷贝到不同的服务器上，这些应用程序一般都是单进程运行。这种整体化架构使得持续交付（一种包含了快速、迭代、升级安全的软件开发过程）变得充满挑战，因为哪怕是应用程序栈的最小增量版本也需要重新编译、重新链接和测试。
什么是微服务？
微服务是一种将应用分解成小的自治服务的软件架构。服务通常仅关注某个特定的目标并保证服务之间的自治。每个服务被独立的开发、测试和部署，每个服务往往使用约定的API并通过网络进行通信，虽然在某些情况下网络可能是本地的。
微服务从SOA发展而来，SOA在本世纪初曾获得广泛的认可和流行，SOA是一种反对大型的整体化架构应用的方式。SOA和微服务的主要区别有：
SOAs是有状态的，而微服务是无状态的。
SOAs倾向于使用企业级的服务总线进行通信，而微服务则使用更简单的通信系统。
SOAs或许会有上百万行代码，而微服务往往仅有少于100行代码。
SOAs强调重用（例如运行时代码、数据库等），而微服务则关注在尽量解耦。
SOAs里的一个系统性变化需要修改软件的整体结构，而在微服务中的一个系统性变化将产生一个新的服务。
SOAs更经常使用传统的关系型数据库，而微服务则更倾向于现代的、非关系型数据库。下面几节将介绍在微服务架构中使用非关系型数据库的好处。
许多架构师发现SOA存在通信协议的问题和缺乏有效的如何分割服务的指导，这些问题构成了微服务的基础，使得微服务成为了实现一个真正的SOA的最佳实践方法。
使微服务成为可能的新技术
需要部署成百甚至上千的服务的缺点跟微服务带来的好处（快速开发、可扩展）相比还是值得的。
新的技术的出现例如容器（Docker、LXC）和编排框架（Kubernetes、Mesos）消除了过去阻碍微服务架构使用的很多问题。
容器是轻量级的运行时环境，使用最少的性能和容量影响提供了隔离性和可扩展性。程序打包也被简化成了相同的环境可以同时支持开发、支持、测试和生产环境的版本，因此使得从开发到测试到QA到生产的过程变得更容易。容器在微服务环境中可以工作的很好因为它可以将服务隔离在单个的容器中。升级一个服务变成了一个可以自动化和可控的过程，在APIs保持不变的情况下修改一个服务不会影响到其它的服务。
当组织开始在大规模环境中运行容器时，或许需要考虑使用编排框架来管理持续增加的复杂性。编排框架帮助部署和管理容器：部署主机、示例容器、错误处理、弹性伸缩。Kubernetes和Mesos是两个常见的编排框架可以使得在微服务环境中部署大量容器变得容易。
获取更多关于如何利用容器和MongoDB构建微服务架构的信息，下载我们的指南：构建微服务：解析容器和编排。
微服务的好处
很多组织可以通过实施微服务来满足现代应用的需求，这些好处包括：
缩短产品上市时间：在整体化架构的应用中，任何微小的修改都需要重新部署整个应用栈，因此带来了更高的风险和复杂度。这造成了更长的版本周期，因为修改可能会被累积，直到达到某个阈值时才发布新的版本。使用微服务，对于某个服务的修改可以被迅速的提交、测试和部署，因为对此服务的修改跟系统的其它部分是不相关的。
持续集成——一种每天数次集成和测试开发人员的代码改动的软件开发实践 – 因为有更少的功能需要去测试而变得更简单和快速。结果是版本的发布节奏更快，因为更少的代码需要被编译和重新测试。编排框架例如Kubernetes通过自动化上线、容器滚动更新和必要时的回滚进一步加快了产品上市的节奏。
灵活性和可扩展性：整体架构的应用需要系统中的全部组件同时扩展。如果某个服务需要更高的性能，唯一的选项就是扩展系统中的所有服务而不是仅仅扩展需要扩容的单个服务。使用微服务，仅需要额外能力的单个服务需要扩容。扩容通过部署更多的容器来实现、可以实现更有效的容量计划，更少的软件授权和更低的总体拥有成本；因为服务和软件可以更好的匹配。
弹性： 整体架构应用的一个主要问题是当某个服务失效时可能整个系统可能都会受到连累。在微服务中，各个服务之间的隔离性使得单个服务的失效不会扩展到系统的其它部分进而造成全局性的影响。如果使用容器，编排框架可以提供额外的弹性：当某个容器失效时，一个新的容器会被启动，进而实现完全的冗余和容量。
组织架构匹配：微服务可以更好的匹配组织架构，因为团队的规模可以根据需要完成的任务进行更好的定义。团队可以被分成更小的小组并专注在应用的某个组件上。这对分布在不同地理位置的团队来讲是非常有用的。例如，在新加坡的团队处理三个服务，在旧金山的团队处理五个服务，这两个团队可以独立的发布和部署功能组件。 这可以帮助处理相同组件的不同职能的团队（Ops、Dev、QA）打破疆界和更好的合作。这也可以保证不同团队之间的沟通跟不同的服务之间的API相匹配。本质上来讲，服务之间的API定义了不同开发团队之间应该相互提供的服务的契约。
降低成本：通过使用容器，应用和环境（设计、测试、生产、支持）可以共享相同的基础设施，结果是更高的硬件利用率和由于管理简化带来的成本降低。另外，微服务也会降低技术方面的开销。在整体化架构的应用中，重构一个大型应用的代码会带来开销（时间、资源）。通过将应用分解成可以通过API访问的微服务，代码重构可以逐个服务进行，结果是更少的时间去维护和更新代码。
第三十四届CIO班招生
北达软EXIN网络空间与IT安全基础认证培训
北达软EXIN DevOps Professional认证培训
责编：yangjun
免责声明：本网站（http://www.ciotimes.com/）内容主要来自原创、合作媒体供稿和第三方投稿，凡在本网站出现的信息，均仅供参考。本网站将尽力确保所提供信息的准确性及可靠性，但不保证有关资料的准确性及可靠性，读者在使用前请进一步核实，并对任何自主决定的行为负责。本网站对有关资料所引致的错误、不确或遗漏，概不负任何法律责任。
本网站刊载的所有内容（包括但不仅限文字、图片、LOGO、音频、视频、软件、程序等）版权归原作者所有。任何单位或个人认为本网站中的内容可能涉嫌侵犯其知识产权或存在不实内容时，请及时通知本站，予以删除。
抢沙发
