一文告诉你微服务究竟是什么

 

微服务等于Spring Cloud？一文告诉你微服务究竟是什么。

19天前2928

微服务初探

什么是微服务

首先微服务并无一个官方的定义，想要直接描述微服务比较困难，咱们能够经过对比传统WEB应用，来理解什么是微服务。

传统的WEB应用核心分为业务逻辑、适配器以及API或经过UI访问的WEB界面。业务逻辑定义业务流程、业务规则以及领域实体。适配器包括数据库访问组件、消息组件以及访问接口等。一个打车软件的架构图以下：

 

尽管也是遵循模块化开发，但最终它们会打包并部署为单体式应用。例如Java应用程序会被打包成WAR，部署在Tomcat或者Jetty上。

这种单体应用比较适合于小项目，优势是：

1.开发简单直接，集中式管理

2.基本不会重复开发

3.功能都在本地，没有分布式的管理开销和调用开销

固然它的缺点也十分明显，特别对于互联网公司来讲：

1.开发效率低：全部的开发在一个项目改代码，递交代码相互等待，代码冲突不断

2.代码维护难：代码功能耦合在一块儿，新人不知道何从下手

3.部署不灵活：构建时间长，任何小修改必须从新构建整个项目，这个过程每每很长

4.稳定性不高：一个微不足道的小问题，能够致使整个应用挂掉

5.扩展性不够：没法知足高并发状况下的业务需求

因此，如今主流的设计通常会采用微服务架构。其思路不是开发一个巨大的单体式应用，而是将应用分解为小的、互相链接的微服务。一个微服务完成某个特定功能，好比乘客管理和下单管理等。每一个微服务都有本身的业务逻辑和适配器。一些微服务还会提供API接口给其余微服务和应用客户端使用。

好比，前面描述的系统可被分解为：

 

每一个业务逻辑都被分解为一个微服务，微服务之间经过REST API通讯。一些微服务也会向终端用户或客户端开发API接口。但一般状况下，这些客户端并不能直接访问后台微服务，而是经过API Gateway来传递请求。API Gateway通常负责服务路由、负载均衡、缓存、访问控制和鉴权等任务。

微服务架构的优势

微服务架构有不少重要的优势。首先，它解决了复杂性问题。它将单体应用分解为一组服务。虽然功能总量不变，但应用程序已被分解为可管理的模块或服务。这些服务定义了明确的RPC或消息驱动的API边界。微服务架构强化了应用模块化的水平，而这经过单体代码库很难实现。所以，微服务开发的速度要快不少，更容易理解和维护。

其次，这种体系结构使得每一个服务均可以由专一于此服务的团队独立开发。只要符合服务API契约，开发人员能够自由选择开发技术。这就意味着开发人员能够采用新技术编写或重构服务，因为服务相对较小，因此这并不会对总体应用形成太大影响。

第三，微服务架构可使每一个微服务独立部署。开发人员无需协调对服务升级或更改的部署。这些更改能够在测试经过后当即部署。因此微服务架构也使得CI／CD成为可能。

最后，微服务架构使得每一个服务均可独立扩展。咱们只需定义知足服务部署要求的配置、容量、实例数量等约束条件便可。好比咱们能够在EC2计算优化实例上部署CPU密集型服务，在EC2内存优化实例上部署内存数据库服务。

微服务架构的缺点和挑战

实际上并不存在silver bullets，微服务架构也会给咱们带来新的问题和挑战。其中一个就和它的名字相似，微服务强调了服务大小，但实际上这并无一个统一的标准。业务逻辑应该按照什么规则划分为微服务，这自己就是一个经验工程。有些开发者主张10-100行代码就应该创建一个微服务。虽然创建小型服务是微服务架构崇尚的，但要记住，微服务是达到目的的手段，而不是目标。微服务的目标是充分分解应用程序，以促进敏捷开发和持续集成部署。

微服务的另外一个主要缺点是微服务的分布式特色带来的复杂性。开发人员须要基于RPC或者消息实现微服务之间的调用和通讯，而这就使得服务之间的发现、服务调用链的跟踪和质量问题变得的至关棘手。

微服务的另外一个挑战是分区的数据库体系和分布式事务。更新多个业务实体的业务交易至关广泛。这些类型的事务在单体应用中实现很是简单，由于单体应用每每只存在一个数据库。但在微服务架构下，不一样服务可能拥有不一样的数据库。CAP原理的约束，使得咱们不得不放弃传统的强一致性，而转而追求最终一致性，这个对开发人员来讲是一个挑战。

微服务架构对测试也带来了很大的挑战。传统的单体WEB应用只需测试单一的REST API便可，而对微服务进行测试，须要启动它依赖的全部其余服务。这种复杂性不可低估。

微服务的另外一大挑战是跨多个服务的更改。好比在传统单体应用中，如有A、B、C三个服务须要更改，A依赖B，B依赖C。咱们只需更改相应的模块，而后一次性部署便可。可是在微服务架构中，咱们须要仔细规划和协调每一个服务的变动部署。咱们须要先更新C，而后更新B，最后更新A。

部署基于微服务的应用也要复杂得多。单体应用能够简单的部署在一组相同的服务器上，而后前端使用负载均衡便可。每一个应用都有相同的基础服务地址，例如数据库和消息队列。而微服务由不一样的大量服务构成。每种服务可能拥有本身的配置、应用实例数量以及基础服务地址。这里就须要不一样的配置、部署、扩展和监控组件。此外，咱们还须要服务发现机制，以便服务能够发现与其通讯的其余服务的地址。所以，成功部署微服务应用须要开发人员有更好地部署策略和高度自动化的水平。

以上问题和挑战可大致归纳为：

• API Gateway
• 服务间调用
• 服务发现
• 服务容错
• 服务部署
• 数据调用

 

幸运的是，出现了不少微服务框架，能够解决以上问题。

第一代微服务框架

Spring Cloud

Spring Cloud为开发者提供了快速构建分布式系统的通用模型的工具（包括配置管理，服务发现，熔断器，智能路由，微代理，控制总线，一次性令牌，全局锁，领导选举，分布式会话，集群状态等）。 主要项目包括：

• spring cloud config：由git存储库支持的集中式外部配置管理。配置资源直接映射到Spring Environment，可是若是须要能够被非Spring应用程序使用。
• spring cloud netflix：与各类Netflix OSS组件（Eureka，Hystrix，Zuul，Archaius等）集成。
• spring cloud bus：用于将服务和服务实例与分布式消息传递联系起来的事件总线。用于在集群中传播状态更改（例如配置更改事件）
• spring cloud for cloud foundry：将您的应用程序与Pivotal Cloudfoundry集成。提供服务发现实现，还能够轻松实现经过SSO和OAuth2保护资源，还能够建立Cloudfoundry服务代理。
• spring cloud cloud foundry service broker：提供构建管理一个Cloud Foundry中服务的服务代理的起点。
• spring cloud cluster：领导选举和通用状态模型（基于zookeeper，redis，hazelcast，Consul的抽象和实现）
• spring cloud consul：结合Hashicorp Consul的服务发现和配置管理
• spring cloud security：在Zuul代理中为负载平衡的OAuth2休眠客户端和认证头中继提供支持。
• spring cloud sleuth：适用于Spring Cloud应用程序的分布式跟踪，与Zipkin，HTrace和基于日志（例如ELK）跟踪兼容。
• spring cloud data flow：针对现代运行时的可组合微服务应用程序的云本地编排服务。易于使用的DSL，拖放式GUI和REST-API一块儿简化了基于微服务的数据管道的总体编排。
• spring cloud stream：轻量级事件驱动的微服务框架，可快速构建可链接到外部系统的应用程序。使用Apache Kafka或RabbitMQ在Spring Boot应用程序之间发送和接收消息的简单声明式模型。
• spring cloud stream app starters：Spring Cloud任务应用程序启动器是Spring Boot应用程序，多是任何进程，包括不会永远运行的Spring Batch做业，而且它们在有限时间的数据处理以后结束/中止。
• spring cloud zookeeper：Zookeeper的服务发现和配置管理
• spring cloud for amazon web services：轻松集成托管的Amazon的Web Services服务。它经过使用spring的idioms和APIs便捷集成AWS服务，例如缓存或消息API。开发人员能够围绕托管服务，没必要关心基础架构来构建应用。
• spring cloud connectors：使PaaS应用程序在各类平台上轻松链接到后端服务，如数据库和消息代理（之前称为“Spring Cloud”的项目）
• spring cloud starters：做为基于spring boot的启动项目，下降依赖管理（在Angel.SR2后，不在做为独立项目）
• spring cloud cli：插件支持基于Groovy预言快速建立spring cloud的组件应用

Dubbo

Dubbo是一个阿里巴巴开源出来的一个分布式服务框架，致力于提供高性能和透明化的RPC远程服务调用方案，以及SOA服务治理方案。其核心部分包含:

• 远程通信: 提供对多种基于长链接的NIO框架抽象封装，包括多种线程模型，序列化，以及“请求-响应”模式的信息交换方式。
• 集群容错: 提供基于接口方法的透明远程过程调用，包括多协议支持，以及软负载均衡，失败容错，地址路由，动态配置等集群支持。
• 自动发现: 基于注册中心目录服务，使服务消费方能动态的查找服务提供方，使地址透明，使服务提供方能够平滑增长或减小机器。

 

可是显而易见，不管是Dubbo仍是Spring Cloud都只适用于特定的应用场景和开发环境，它们的设计目的并非为了支持通用性和多语言性。而且它们只是Dev层的框架，缺乏DevOps的总体解决方案（这正是微服务架构须要关注的）。而随之而来的即是Service Mesh的兴起。

下一代微服务：Service Mesh？

Service Mesh

Service Mesh又译做“服务网格”，做为服务间通讯的基础设施层。若是用一句话来解释什么是Service Mesh，能够将它比做是应用程序或者说微服务间的TCP/IP，负责服务之间的网络调用、限流、熔断和监控。对于编写应用程序来讲通常无须关心TCP/IP这一层（好比经过 HTTP 协议的 RESTful 应用），一样使用Service Mesh也就无须关系服务之间的那些原来是经过应用程序或者其余框架实现的事情，好比Spring Cloud、OSS，如今只要交给Service Mesh就能够了。

Service Mesh有以下几个特色：

• 应用程序间通信的中间层
• 轻量级网络代理
• 应用程序无感知
• 解耦应用程序的重试/超时、监控、追踪和服务发现

Service Mesh的架构以下图所示：

 

Service Mesh做为Sidebar运行，对应用程序来讲是透明，全部应用程序间的流量都会经过它，因此对应用程序流量的控制均可以在Service Mesh中实现。

目前流行的Service Mesh开源软件有Linkerd、Envoy和Istio，而最近Buoyant（开源Linkerd的公司）又发布了基于Kubernetes的Service Mesh开源项目Conduit。

Linkerd

Linkerd是开源网络代理，设计为以服务网格部署：用于管理，控制和监控应用程序内的服务与服务间通信的专用层。

Linkerd旨在解决Twitter，Yahoo，Google和Microsoft等公司运营大型生产系统时发现的问题。根据经验，最复杂，使人惊奇和紧急行为的来源一般不是服务自己，而是服务之间的通信。Linkerd解决了这些问题，不只仅是控制通信机制，而是在其上提供一个抽象层。

 

它的主要特性有：

• 负载平衡：linkerd提供了多种负载均衡算法，它们使用实时性能指标来分配负载并减小整个应用程序的尾部延迟。
• 熔断：linkerd包含自动熔断，将中止将流量发送到被认为不健康的实例，从而使他们有机会恢复并避免连锁反应故障。
• 服务发现：linkerd 与各类服务发现后端集成，经过删除特定的(ad-hoc)服务发现实现来帮助您下降代码的复杂性。
• 动态请求路由：linkerd 启用动态请求路由和从新路由，容许您使用最少许的配置来设置分段服务(staging service)，金丝雀(canaries)，蓝绿部署(blue-green deploy)，跨DC故障切换和黑暗流量(dark traffic)。
• 重试次数和截止日期：linkerd能够在某些故障时自动重试请求，而且能够在指定的时间段以后让请求超时。
• TLS：linkerd 能够配置为使用 TLS 发送和接收请求，您可使用它来加密跨主机边界的通讯，而不用修改现有的应用程序代码。
• HTTP代理集成：linkerd 能够做为 HTTP 代理，几乎全部现代 HTTP 客户端都普遍支持，使其易于集成到现有应用程序中。
• 透明代理：您能够在主机上使用 iptables 规则，设置经过 linkerd 的透明代理
• gRPC：linkerd 支持 HTTP/2 和 TLS，容许它路由 gRPC 请求，支持高级 RPC 机制，如双向流，流程控制和结构化数据负载。
• 分布式跟踪：linkerd 支持分布式跟踪和度量仪器，能够提供跨越全部服务的统一的可观察性。
• 仪器仪表: linkerd 支持分布式跟踪和度量仪器，能够提供跨越全部服务的统一的可观察性。

Envoy

Envoy 是一个面向服务架构的L7代理和通讯总线而设计的，这个项目诞生是出于如下目标：

对于应用程序而言，网络应该是透明的，当发生网络和应用程序故障时，可以很容易定位出问题的根源。

Envoy可提供如下特性：

• 外置进程架构：可与任何语言开发的应用一块儿工做；可快速升级
• 基于新C++11编码：可以提供高效的性能
• L3/L4过滤器：核心是一个L3/L4网络代理，可以做为一个可编程过滤器实现不一样TCP代理任务，插入到主服务当中。经过编写过滤器来支持各类任务，如原始TCP代理、HTTP代理、TLS客户端证书身份验证等。
• HTTP L7过滤器：支持一个额外的HTTP L7过滤层。HTTP过滤器做为一个插件，插入到HTTP连接管理子系统中，从而执行不一样的任务，如缓冲，速率限制，路由/转发，嗅探Amazon的DynamoDB等等。
• 支持HTTP/2：在HTTP模式下，支持HTTP/1.一、HTTP/2，而且支持HTTP/1.一、HTTP/2双向代理。这意味着HTTP/1.1和HTTP/2，在客户机和目标服务器的任何组合均可以桥接
• HTTP L7路由：在HTTP模式下运行时，支持根据content type、runtime values等，基于path的路由和重定向。可用于服务的前端／边缘代理
• 支持gRPC：gRPC是一个来自谷歌的RPC框架，使用HTTP/2做为底层的多路传输。HTTP/2承载的gRPC请求和应答，均可以使用Envoy的路由和LB能力
• 支持MongoDB L7：支持获取统计和链接记录等信息
• 支持DynamoDB L7：支持获取统计和链接等信息
• 服务发现：支持多种服务发现方法，包括异步DNS解析和经过REST请求服务发现服务
• 健康检查：含有一个健康检查子系统，能够对上游服务集群进行主动的健康检查。也支持被动健康检查。
• 高级LB：包括自动重试、断路器，全局限速，阻隔请求，异常检测。将来还计划支持请求速率控制
• 前端代理：可做为前端代理，包括TLS、HTTP/1.一、HTTP/2，以及HTTP L7路由
• 极好的可观察性：对全部子系统，提供了可靠的统计能力。目前支持statsd以及兼容的统计库。还能够经过管理端口查看统计信息，还支持第三方的分布式跟踪机制
• 动态配置：提供分层的动态配置API，用户可使用这些API构建复杂的集中管理部署

Istio

Istio是一个用来链接、管理和保护微服务的开放平台。Istio提供一种简单的方式来创建已部署服务网络，具有负载均衡、服务间认证、监控等功能，而不须要改动任何服务代码。想要为服务增长对Istio的支持，您只须要在环境中部署一个特殊的边车（sidecar），使用Istio控制面板功能配置和管理代理，拦截微服务之间的全部网络通讯。

Istio目前仅支持在Kubernetes上的服务部署，但将来版本中将支持其余环境。

Istio提供了一个完整的解决方案，经过为整个服务网格提供行为洞察和操做控制来知足微服务应用程序的多样化需求。它在服务网络中统一提供了许多关键功能：

• 流量管理：控制服务之间的流量和API调用的流向，使得调用更可靠，并使网络在恶劣状况下更加健壮
• 可观察性：了解服务之间的依赖关系，以及它们之间流量的本质和流向，从而提供快速识别问题的能力
• 策略执行：将组织策略应用于服务之间的互动，确保访问策略得以执行，资源在消费者之间良好分配。策略的更改是经过配置网格而不是修改应用程序代码
• 服务身份和安全：为网格中的服务提供可验证身份，并提供保护服务流量的能力，使其能够在不一样可信度的网络上流转

Istio服务网格逻辑上分为数据面板和控制面板：

• 数据面板由一组智能代理（Envoy）组成，代理部署为边车，调解和控制微服务之间全部的网络通讯
• 控制面板负责管理和配置代理来路由流量，以及在运行时执行策略

下图显示了构成每一个面板的不一样组件：

 

Conduit

Conduit是为Kubernetes设计的一个超轻型服务网格服务，它可透明地管理在Kubernetes上运行的服务的运行时通讯，使得它们更安全可靠。Conduit提供了可见性、可靠性和安全性的功能，而无需更改代码。

Conduit service mesh也是由数据面板和控制面板组成。数据面板承载应用实际的网络流量。控制面板驱动数据面板，并对外提供北向接口。

对比

Linkerd和Envoy比较类似，都是一种面向服务通讯的网络代理，都可实现诸如服务发现、请求路由、负载均衡等功能。它们的设计目标就是为了解决服务之间的通讯问题，使得应用对服务通讯无感知，这也是Service Mesh的核心理念。Linkerd和Envoy像是分布式的Sidebar，多个相似Linkerd和Envoy的proxy互相链接，就组成了service mesh。

而Istio则是站在了一个更高的角度，它将Service Mesh分为了Data Plane和Control Plane。Data Plane负责微服务间的全部网络通讯，而Control Plane负责管理Data Plane Proxy：

 

而且Istio天生的支持Kubernetes，这也弥合了应用调度框架与Service Mesh之间的空隙。

关于Conduit的资料较少，从官方介绍看它的定位和功能与Istio相似。

Kubernetes + Service Mesh

Kubernets已经成为了容器调度编排的事实标准，而容器正好能够做为微服务的最小工做单元，从而发挥微服务架构的最大优点。因此我认为将来微服务架构会围绕Kubernetes展开。而Istio和Conduit这类Service Mesh天生就是为了Kubernetes设计，它们的出现补足了Kubernetes在微服务间服务通信上的短板。虽然Dubbo、Spring Cloud等都是成熟的微服务框架，可是它们或多或少都会和具体语言或应用场景绑定，并只解决了微服务Dev层面的问题。若想解决Ops问题，它们还需和诸如Cloud Foundry、Mesos、Docker Swarm或Kubernetes这类资源调度框架作结合：

 

可是这种结合又因为初始设计和生态，有不少适用性问题须要解决。

Kubernetes则不一样，它自己就是一个和开发语言无关的、通用的容器管理平台，它能够支持运行云原生和传统的容器化应用。而且它覆盖了微服务的Dev和Ops阶段，结合Service Mesh，它能够为用户提供完整端到端的微服务体验。

因此我认为，将来的微服务架构和技术栈多是以下形式：

 

多云平台为微服务提供了资源能力（计算、存储和网络等），容器做为最小工做单元被Kubernetes调度和编排，Service Mesh管理微服务的服务通讯，最后经过API Gateway向外暴露微服务的业务接口。

我相信将来随着以Kubernetes和Service Mesh为标准的微服务框架的盛行，将大大下降微服务实施的成本，最终为微服务落地以及大规模使用提供坚实的基础和保障。