Day17_02_SpringCloud教程之微服务简介

02_SpringCloud教程之微服务简介

一. 微服务简介

1. 微服务概述

首先微服务并没有一个官方的定义,微服务的概念一开始源于 2014 年 3 月 Martin Fowler 所写的一篇文章“Microservices”. 文中内容提到: 微服务架构是一种架构模式,它提倡将单一应用程序划分成一组小的服务,服务之间互相协调、互相配合,为用户提供最终价值.

每个服务运行在其独立的进程中,服务与服务间采用轻量级的通信机制互相沟通(通常是基于 HTTP 的 RESTful API),每个服务都围绕着具体业务进行构建,并且能够被独立地部署到生产环境、类生产环境等.

2. 什么是微服务架构?

Martin Flower对微服务的定义:

In short, the microservice architectural style is an approach to developing a single application as a suite of small services, 
each running in its own process and communicating with lightweight mechanisms, often an HTTP resource API. 
These services are built around business capabilities and independently deployable by fully automated deployment machinery. 
There is a bare minimum of centralized management of these services, 
which may be written in different programming languages and use different data storage technologies.

简单的说,微服务就是软件系统架构中的一种设计风格,它倡导将一个原本独立的系统分成多个小型服务,这些小型服务都在各自独立的进程中运行,服务之间通过基于 HTTP 的 RESTful 轻量级 API 进行通信协作.被拆分的每个微服务围绕系统中的某项或一些耦合度较高的业务进行构建,并且每个服务都维护着自身的数据存储、业务开发、自动化测试案例以及独立部署机制.由于有了轻量级的通信机制,这些微服务间可以使用不通的语言来编写.

3. 微服务的拆分粒度

微服务到底拆分到多大的一个粒度,更多时候是需要在粒度与团队之间找到一个平衡点. 微服务越小,微服务独立性带来的好处就越多,但是管理大量微服务也会越复杂.基本上拆分需要遵循以下几个原则:

• 单一职责原则: 即"把因相同原因而变化的东西聚合到一起,把因不同原因而变化的东西分离开来",通过这个原则确定微服务边界;
• 团队自主原则: 团队越大,沟通与协助成本就会越高,我们在实践中一个团队不会超过 8 人,团队内全栈,是一个全功能团队;
• 先分数据库、后分服务: 数据模型能否彻底分开,决定了微服务的边界功能是否彻底划清,实践中我们先讨论数据模型边界,数据模型的边界映射了业务的边界,进而从底向上完成服务拆分.

二. 微服务涉及到的技术栈



三. 微服务为什么采用SpringCloud

1. 微服务架构概述

简单来说,服务化的核心就是将传统的一站式应用根据业务拆分成一个一个的小的服务.而微服务在这个基础上要更彻底地去耦合(不再共享DB、KV,去掉重量级ESB),并且强调DevOps和快速演化.这就要求我们必须采用与一站式时代、泛SOA时代不同的技术栈,而Spring Cloud就是其中的佼佼者.

DevOps是英文Development和Operations的合体,它要求开发、测试、运维进行一体化的合作,
进行更小、更频繁、更自动化的应用发布,以及围绕应用架构来构建基础设施的架构. 
这就要求应用充分的内聚,也方便运维和管理,这个理念与微服务理念不谋而合.

2. 为什么微服务架构需要Spring Cloud?

2.1 从使用nginx说起

最初的服务化解决方案是给提供相同服务的提供者一个统一的域,然后服务调用者向这个域名发送HTTP请求,由Nginx负责请求的分发和跳转.



但是这种架构存在很多问题:

• Nginx作为中间层,在配置文件中耦合了服务调用者的逻辑,这削弱了微服务的完整性,也使得Nginx在一定程度上变成了一个重量级的ESB;
• 服务的信息分散在各个系统,无法统一管理和维护.每一次的服务调用都是一次尝试,服务消费者并不知道有哪些实例在给他们提供服务,这不符合DevOps的理念;
• 无法直观的看到服务提供者和服务消费者当前的运行状况和通信频率,这也不符合DevOps的理念;
• 消费者的失败重发,负载均衡等都没有统一策略,这加大了开发每个服务的难度,不利于快速演化.

为了解决上面的问题,我们需要一个现成的中心组件对服务进行整合,将每个服务的信息汇总,包括服务的组件名称、地址、数量等.服务的调用方在请求某项服务时首先通过中心组件获取提供这项服务的实例的信息(IP、端口等),再通过默认或自定义的策略选择该服务的某一提供者直接进行访问.所以,我们引入了Dubbo!

2.2 基于Dubbo实现微服务

Dubbo是阿里开源的一个SOA服务治理解决方案,文档丰富,在国内的使用度也非常高.

使用Dubbo构建的微服务,可以比较好地解决上面提到的问题.



• 调用中间层变成了可选组件,消费者可以直接访问服务提供者;
• 服务信息被集中到Registry中,形成了服务治理的中心组件;
• 通过Monitor监控系统,可以直观地展示服务调用的统计信息;
• Consumer可以进行负载均衡、服务降级的选择.

但是对于微服务架构而言,Dubbo也并不是十全十美的:

• Registry严重依赖第三方组件(zookeeper或者redis),当这些组件出现问题时,服务调用很快就会中断;
• Dubbo只支持RPC调用,使得服务提供方与调用方在代码上产生了强依赖,服务提供者需要不断将包含公共代码的jar包打包出来供消费者使用,一旦打包出现问题,就会导致服务调用出错;
• 最为重要的是,Dubbo现在已经重新维护了,对于技术发展的新需求,需要由开发者自行拓展升级.

2.3 新的选择——Spring Cloud

作为新一代的微服务框架,Spring Cloud提出的口号是开发“面向云环境的应用程序”,它为微服务架构提供了更加全面的技术支持.

结合我们一开始提到的微服务的诉求,我们把Spring Cloud与Dubbo进行一番对比:



Spring Cloud抛弃了Dubbo的RPC通信,采用的是基于HTTP的REST方式.严格来说,这两种方式各有优劣.虽然从一定程度上来说,后者牺牲了服务调用的性能,但也避免了上面提到的原生RPC带来的问题.而且REST相比RPC更为灵活,服务提供方和调用方的依赖只依靠一纸契约,不存在代码级别的强依赖,这在强调快速演化的微服务环境下,显得更加合适.

很显然,Spring Cloud的功能比Dubbo更加强大,涵盖面更广.而且作为Spring的拳头项目,它也能够与Spring Framework、Spring Boot、Spring Data、Spring Batch等其他Spring项目完美融合,这些对于微服务而言是至关重要的.前面提到,微服务背后一个重要的理念就是持续集成、快速交付,而在服务内部使用一个统一的技术框架,显然比把分散的技术组合到一起更有效率.

四. 微服务拆分原则

• 横向拆分:按照不同的业务域进行拆分,例如订单、营销、风控、积分资源等,形成独立的业务领域微服务集群;
• 纵向拆分:把一个业务功能里的不同模块或者组件进行拆分.例如把公共组件拆分成独立的原子服务,下沉到底层,形成相对独立的原子服务层.这样一纵一横,就可以实现业务的服务化拆分.

五. 微服务分类



• 基础服务: 是一些基础组件,与具体的业务无关. 比如: 短信服务、邮件服务.这里的服务最容易摘出来做微服务,也是我们第一优先级分离出来的服务;
• 业务服务: 是一些垂直的业务系统,只处理单一的业务类型,比如: 风控系统、积分系统、合同系统;
• 接口服务: 根据业务情况来选择是否迁移,比如: 如果突然有需求对积分系统进行大优化,我们就趁机将积分系统进行改造,是我们的第二优先级分离出来的服务;
• 前置服务: 前置服务一般为服务的接入或者输出服务,比如网站的前端服务、app 的服务接口这类,这是我们第三优先级分离出来的服务.

六. 微服务的发展

1. 第一代微服务框架

1.1 Spring Cloud

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

1.2 Dubbo

Dubbo是一个阿里巴巴开源出来的一个分布式服务框架,致力于提供高性能和透明化的RPC远程服务调用方案,以及SOA服务治理方案.

1.3 总结

但是显而易见,无论是Dubbo还是Spring Cloud都只适用于特定的应用场景和开发环境,它们的设计目的并不是为了支持通用性和多语言性.并且它们只是Dev层的框架,缺少DevOps的整体解决方案(这正是微服务架构需要关注的),而随之而来的便是Service Mesh的兴起.

2. 第二代微服务框架

2.1 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.

2.2 Linkerd

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

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



2.3 Envoy

Envoy 是一个面向服务架构的L7代理和通信总线而设计的,这个项目诞生是出于以下目标:

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

2.4 Istio

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

Istio目前仅支持在Kubernetes上的服务部署,但未来版本中将支持其他环境.

2.5 Conduit

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

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

2.6 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为标准的微服务框架的盛行,将大大降低微服务实施的成本,最终为微服务落地以及大规模使用提供坚实的基础和保障.