微服务行业分析报告.docx

微服务行业分析报告.docx

《微服务行业分析报告.docx》由会员分享，可在线阅读，更多相关《微服务行业分析报告.docx（20页珍藏版）》请在冰豆网上搜索。

微服务行业分析报告

2018年微服务行业分析报告

2018年9月

2014年，MartinFowler等人出版了一本新书《BuildingMicroservices》，该书描述了如何按照微服务架构模式设计及搭建一个具有良好扩展性并可持续开发的系统。

此后，该架构模式迅速被业界所熟知，成为市场关注重点，并尝试在产品中逐渐应用。

当前时点，国内上市公司逐渐在微服务及架构相关领域加大投入力量，一级市场初创公司亦层出不穷，但资本市场对微服务架构尚缺乏了解。

本篇报告基于上述原因，从科普角度出发，希望能为市场解答有关微服务的四大基本问题：

1.什么是微服务架构？

微服务架构其与此前的一体化架构（Monolith）以及面向服务的架构（SOA）相比有何区别？

2.微服务架构具体实现路径是怎样的？

其技术壁垒何在？

3.微服务架构适用于什么样的场景？

4.当前时点，国内市场微服务架构落地情况如何？

IT服务商将如何切入这一蓝海市场？

上市公司中有哪些已经开始相应布局？

什么是微服务架构？

微服务架构（MicroServicesArchitecture，MSA）提倡将庞大规模应用分割成一系列细粒度的服务，每个服务专注于单一业务功能，可独立运行，服务之间采用轻量级通信机制相互沟通、配合来实现完整的应用。

相比于前序一体化架构和SOA架构，MSA在部署效率、伸缩弹性和容错性等方面具备优势，满足当前互联网与云计算趋势下企业IT系统对敏捷性的不懈追求。

微服务架构是如何实现的？

一方面，需要根据企业自身业务框架进行梳理，有效切分现有的单体架构并进行领域设计，这一过程体现明显个性化，企业往往通过外部引入咨询专家+内部IT团队配合的方式完成；另一方面，需要基于容器云技术搭建微服务平台以实现多组件管理，主要包括开发框架、以及周边配套工具链等全套体系的构建。

微服务架构适合什么样的场景？

微服务架构与云计算相辅相成。

一方面，微服务架构的推广很大程度上得益于云计算渗透率的提升，另一方面，微服务架构能够显著提升企业云端迁移效率，从而推动大型企业IT系统上云进程。

微服务架构当前市场进展如何？

微服务架构在大型互联网公司中已有成熟的规模化应用，Netflix、Wikipedia等公司已将自身IT架构基于微服务完成重构；而在下游企业用户端，制造业和金融业有望率先实现规模化落地。

当前时点，IT服务商开始早期布局，切入微服务市场的途径主要包括以下三种：

（1）提供通用型平台；

（2）提供微服务应用软件；（3）提供全栈技术咨询与实施服务，其中咨询实施服务作为最佳切入点，行业竞争相对激烈。

参与者主要包括初创企业和传统IT服务商两类：

初创企业如灵雀云、DaoCloud、博云等平台技术能力较强，目前落地项目数量占优；而传统实施服务商具备充分行业累积，有望逐步追赶。

自2016年起上市公司均已开始积极布局，用友网络、赢时胜、金蝶国际、华宇软件、信雅达、东软集团等均有成熟产品推出，亦不乏标杆性项目落地；如润和软件等公司，通过战略投资初创企业的方式参与市场；而天玑科技、金证股份等公司目前已开展研发与验证。

一、微服务架构定义

微服务架构（MSA，MicroServicesArchitecture）是一种架构风格和设计模式，它提倡将应用分割成一系列细粒度的服务，每个服务专注于单一业务功能，运行于独立的进程中，服务之间边界清晰，采用轻量级通信机制（如HTTP/REST）相互沟通、配合来实现完整的应用，满足业务和用户的需求。

从上述定义中可以看出，微服务架构的本质主要体现在三方面，其一为“细粒度切分”，其二为“独立进程”，其三为“轻量级通信”，而这也是微服务架构与前序架构主要区别所在。

因此，我们沿企业级IT服务架构发展脉络追溯其演进历史，以期对这三大特点更深入地了解。

总体来看，企业级IT服务架构处于不断演进过程，绝非一蹴而就：

平台随着业务的发展从AllinOne环境就可以满足业务需求（以Java来说，可能只是一两个war包就解决了），展到需要拆分多个应用，加快开发效率；再发展到服务越来越多，不得不将一些核心或共用的服务拆分出来，并由企业服务总线（EnterpriseServiceBus，ESB）等抽象层统筹管理；再到近来兴起的微服务架构，总体来看，伴随软件代码库的扩张，IT整体架构基本遵循耦合由紧变松，粒度由粗变细的规律。

1、第一阶段：

单体架构

单体架构（Monolith，又称巨石架构）是IT服务架构初始状态。

在应用程序开发早期阶段，代码数量有限，开发者只需要一个应用将所有功能部署在一起，即可满足业务需求。

随后出现了传统的经典三层架构:

表现层（UI）、业务逻辑层（BLL）、数据访问层（DAL）。

时至今日,这种多层次的一体化应用构架仍然是许多应用的首选：

层次划分清晰，层与层之间有比较明确的接口，从程序逻辑层面非常易于理解。

一体化在公司早期规模尚小阶段具备明显优势：

在项目初期，巨石架构能够使程序员更容易开发、测试和部署。

但随着应用程序逐渐增长，业务复杂度会变的越来越高。

这种情况下三层构架拥有难以维护、难以扩展两大痛点，从而最终影响应用系统的使用，并不适合业务的继续发展。

（1）痛点1：

应用代码紧密耦合，拖累维护效率

一体化架构将所有的代码及功能都包含在一个程序包中，各功能模块之间紧密耦合，牵一发而动全身。

随着项目的逐渐变大，程序更改、开发效率将急剧下降，即使只更改一行代码，也要将整体程序进行编译部署，随之而来的是更新后整体可用性风险的提升。

（2）痛点2：

应用代码高度集成，无法弹性扩展

由于所有代码集成于一个程序，因此在对服务的容量进行扩展的时候，只能选择重复地部署整体程序来扩展服务能力，而不是仅仅扩展出现系统瓶颈的组份，造成硬件资源的极大浪费。

后续出现的垂直架构，实际上是一体化结构的扩展，其将相互之间关联较少的应用功能集成为模块化的子系统进行独立部署（见图1），某种程度上解决了一体化架构面临的扩容问题，流量可以分散到各个子系统中，且系统体积可控，提升了开发效率。

但随着项目不断扩容，当垂直应用越来越多时，应用之间交互、调用不可避免，垂直架构容易形成“信息孤岛”，不同子系统之间往往会出现“重复造轮子”，并不能从根本上解决伴随项目容量扩张而产生的种种问题。

因此，将应用程序中紧密关联的各项子功能解耦，以实现各功能模块独立部署，已成为满足应用程序快速更新、弹性扩展需求的最佳解决途径。

2、第二阶段：

面向服务的架构（SOA）

了解决早期企业为了实现系统扩容而建设的独立的子系统间信息孤岛的问题，面向服务的架构（Service-OrientedArchitecture）应运而生，将应用程序的不同功能单元单独整合成为服务，并将这些服务通过定义良好的接口和契约联系起来，实现应用间服务级复用。

市场普遍认为，SOA体现了明显的解耦思想，是一种粗粒度、相对松耦合的服务架构。

服务之间通过简单、精确定义的接口进行通讯，不涉及底层编程接口和通讯模型，整个系统的可维护性、可扩展性相对于单体型架构得到提高。

SOA架构下，服务间通信依赖中心化调度平台。

当服务越来越多，服务容量的难以准确评估，小服务导致资源浪费等问题逐渐显现，此时需增加一个调度中心基于访问压力实时管理集群容量，提高集群利用率。

企业服务总线（ESB）就是这样一种统筹这些服务间的重用、可靠地集成企业信息系统中存在的各种技术协议和应用、同时隐藏各种应用和技术带来的底层复杂性的以服务为中心的抽象层。

虽然在SOA架构下，整个系统的可维护性、可扩展性相对于单体型架构得到提高，但其仍存在一定局限，具体来看：

（1）SOA架构中，各项服务间通信、调用完全依赖ESB，利用可热插拔的中间件以及消息队列来完成服务与服务之间的解耦，对于总线结构的依赖也使得服务的独立性并没有被完全剥离。

ESB可能成为影响整个系统的单一故障点：

由于每个服务都通过ESB进行通信，如果其中一个服务变慢，可能会阻塞ESB并请求该服务。

（2）SOA架构注重水平服务，各项服务之间的隔离性仍有局限；SOA架构下，粗粒度服务的切分往往以功能为导向，在服务间强调业务重用，鼓励组件共享，因此各服务间仍存在较强依赖关系，这种依赖关系从某种方面来说亦是一种耦合的体现，当某一服务发生故障或需要升级时，仍然会影响到系统整体的运行，拖累系统整体运维效率。

3、第三阶段：

微服务架构（MSA）

微服务架构（MicroServiceArchitecture）将一个大型复杂软件应用拆分成为多个微服务组件，各个松散耦合的微服务间可被独立部署。

每个微服务仅关注于完成一件任务并很好地完成该任务，每个任务代表着一个细分的业务能力。

实际上，“微服务”是一个概括性的术语，目前尚缺少对其精准的定义。

因此，我们希望通过与单体架构和SOA架构进行对比，来阐述微服务架构的主要特点。

微服务与单体架构的差别主要体现为“细粒度拆分”。

具体来看，微服务将原有大型程序按照功能模块进行拆分，实现单体应用程序中紧密关联的各项子功能之间的解耦，各功能模块独立部署，使得微服务架构具备一定优势：

虽然项在项目模较小时期，一体化架构开发时间相对较短，项目推出较快，但随着后续项目规模逐步扩大，微服务架构在应用推出、运维更新方面均具备显著敏捷性优势；此外，由于微服务之间采取松耦合模式，各模块之间相对独立、互不干扰，因此微服务架构同时具备容错性提升、可弹性扩展的优势。

微服务架构与SOA差别主要体现为“独立进程”和“轻量级通信”。

微服务架构和SOA架构在以服务为核心、通过服务间松散耦合的方式敏捷快速地推出市场这一核心理念方面一脉相承，因此，行业内部分人将微服务架构视作SOA架构的进一步延伸，认为微服务架构是更细粒度的SOA，或者说，是SOA的另一种部署形式。

但与此同时，我们也需要关注微服务架构与SOA架构的明显不同：

一方面，在服务拆分的过程中，微服务注重垂直拆分，以保证各服务之间的独立性。

SOA注重水平拆分，设计过程中往往将服务分层（ServiceLayers模式），在粗粒度拆分的时候注重功能性，并通过ESB实现跨服务调用以完成应用需求，因此服务间的耦合性仍然存在。

而微服务在做切分的时候则注重服务独立性，边界明显，微服务之间相对隔离，为此微服务通常有自己独立的数据库，微服务通常是直接面对用户的，直接为用户提供从接入层到某个功能，由此保证各微服务之间的独立性。

另一方面，微服务强调服务应用的去中心化治理，采取轻量级服务间通信，通俗的比喻可以将微服务及其通信视作“智能端点与扁平管道”，这与SOA架构中统一的调度平台ESB背道而驰，相当于进一步打散了各服务模块之间的耦合关系。

因此，相比于SOA需要自上而下的进行架构方法论的统筹规划，微服务架构能够进行自下而上的设计：

只要用户存在需求，就可以先把某一项服务/业务剥离，随后针对性的确认业务需求，完成快速开发迭代，开发/部署过程中的敏捷性得以进一步体现。

微服务架构的核心在于，通过有效的应用拆分，保证各模块之间的独立性。

无论是垂直化的拆分方式，还是去中心化的服务管理，其本质上都是为了实现各服务之间的独立性，使得微服务架构具备高内聚、松耦合的特点，在此基础之上，微服务架构拥有显著优势：

（1）敏捷性

使用微服务的组织由多个负责运维独立服务的小团队组成。

各个团队都是在界限明确的小范围内独立、快速地工作，从而起到减小迭代时间的效果。

各个小团队效率的提升将使整个企业组织工作效率进行很大程序的提高。

（2）伸缩性

合理解耦的微服务架构，可以独立地进行水平伸缩扩展。

相比于传统架构中，当业务量、流量增大时，往往采用升级硬件资源的方式，这将导致“机器硬件资源上限”和伸缩时宕机的问题。

而采用微服务架构，可通过虚拟化手段实现动态地适配流量，整个水平伸缩的过程将会是自动化的。

（3）可用性

一方面，微服务架构允