微服务技术讲解

微服务技术讲解

微服务的产生

单体应用:

最大的缺点:

  1. 模块及功能的耦合

  2. 无法扩展、容易达到性能瓶颈

  3. 发布会影响整体的可用性

  4. 无法故障隔离

 

 

 

解决方法:

SOA简介

最大缺点:

  1. 如果所有功能(服务)在一个应用域,在性能拓展时,虽然可以进行“横向扩充”(“应用集群”),但是还是无法解决“数据库瓶颈”、“不同模块(服务)对硬件资源冲突的隔离”;

 

 

 

SOA产生的背景:

组织与业务流程频繁变化

  • IT建设以部门为主,业务流程与数据局限于部门内部

  • 竖井应用:不同应用、不同厂商,会形成不同的数据结构、不同的实现

  • 从关注部门需求到关注企业需求,需要部门间数据共享/业务共享/客户共享

SOA解决的问题:

  1. 信息孤岛

  2. 互联互通

  3. 业务重用

 

微服务简介

目标:像换零件一样去替换

  • 全称微服务架构:,缩写为MSA

  • Martin Fowler的定义:

    • 微服务架构是一种架构模式,它提倡将单一应用程序划分为一组小的服务,服务之间互相协调、互相配合,为用户提供最终价值。每个服务运行在其独立的进程中,服务与服务间采用轻量级的通信机制互相沟通(通常是基于HTTP的RESTful API)。每个服务都围绕着具体业务进行构建并且能够被独立地部署在生产环境、预发布环境等。另外,应尽量避免统一的、集中式的服务管理机制,对具体一个服务而言,应根据应用上下文,选择合适的语言、工具对其进行构建。

微服务的几大特征

  • 由一组小的服务组成一个完整的应用(或网站)

  • 每个服务围绕一个相对独立的业务领域(领域模型)构建

  • 服务之间通过轻量级的通信机制互相沟通

  • 完全的去中心化

  • 每个服务都可以独立部署

  • 每个服务可以使用不同的编程语言实现

 

微服务架构的起源-企业转型

传统应用

  • 服务内部用户为主

  • 需求明确、功能全、覆盖广、大集成、中央控制、适合稳定发展阶段

  • 刚性强,难以快速变化,维护成本高,快速变革的新业态无法支持

新兴互联网应用
  • 服务外部客户和合作伙伴

  • 需求变动快,功能简单,独立和分散,分布式进化,一切从零开始,业务与 IT 无法分开,需要快速创新

  • 运用规模变化大,大范围广泛的尝试,易失败(淘汰),对业务弹性、快速发布要求高

传统企业的IT建设需要转型,需要面向外部客户,需要应对外部环境的快速变化、需要快速创新,IT架构也需要向互联网企业学习作出相应的改进,来支撑企业的数字化转型。先是单块架构,后来为了具备一定的扩展和可靠性,就有了垂直架构,也就是加了个负载均衡,接下来是SOA,解决应用系统之间如何集成和互通,微服务架构则是进一步在探讨一个应用系统该如何设计才能够更好的使开发、管理更加灵活高效。

 

延伸知识——TOGAF架构

TOGAF由国际标准权威组织The Open Group制定。1993年开始应客户要求制定系统架构的标准,在1995年发表(TOGAF)架构框架。TOGAF的基础是美国国防部的信息管理技术架构,是基于一个迭代的过程模型,支持最佳实践和一套可重用的现有架构资产。它可设计、评估、并建立组织的正确架构。

企业架构方法有很多,但TOGAF是最主流的。

 

微服务架构起源——问题

单体应用

  • 功能集中

  • 代码与数据中心化

  • 在一个包中发布

  • 运行在一个进程中

带来的问题

  1. 开发效率低

  2. 交付周期长

  3. 技术转型难

  4. 新人培养周期长

 

微服务与SOA的区别(1):

 

 

 

  • SOA没有为服务如何划分提出具体指导

  • SOA无法防止服务之间过度耦合

  • SOA通常使用重量级的通信协议,例如SOAP/WSDL

  • SOA中常常有集中式的服务管理机制,例如UDDI、ESB

  • SOA未强调服务的独立部署

  • SOA的性能和可伸缩性无法满足面向互联网大流量应用的需要

微服务与SOA的区别(2)

SOA和微服务的区别:

  • 微服务不再强调传统SOA架构里面比较重的ESB企业服务总线

  • SOA的思想进入到单个业务系统内部实现真正的组件化

SOA和微服务的共同点:

  • 服务化

  • 敏捷快速

架构设计发展:

MVC(视图、业务逻辑前后端分离) ---> SOA(大型系统分层解耦) ---> Micro services(云计算产物,关注敏捷交付)

 

微服务原理

微服务简介

松耦合:

  1. 接口与业务无关性,即:标准化接口

  2. 服务间可组合,即:复用

最大优点:

  1. 所有功能(服务)可以单独小应用部署,实现真正意义上的“横向扩充”(理论上对服务进行各种方式单独或组合部署),解决“数据库瓶颈”、“不同模块(服务)对硬件资源冲突的隔离”。

  2. 因为独立,所以可以快速迭代,易部署。

 

微服务基本架构

  1. 服务自动注册:

    1. 告诉API网关有这么一T务可以对外供调用了

    2. 自动加入负载均衡副本机制

  2. 服务优雅降级,与“服务自动注册”相反;

  3. 负载均衡

  4. 流量管控、访问黑名单机制

  5. 基于容器(如: Docker)小应用(AP)部署

  6. 提供一个总服务来对其他服务进行组合调用(对组合中成员实现同步执行、异步执行机制)

  7. 实现分布式事务

 

微服务架构的定义

  • 小,且专注于做一件事

  • 独立的进程中

  • 小轻量级的通信机制

  • 松耦合、独立部署

微服务架构是一种架构模式,它提倡将单一应用程序划分成一组小的服务,服务之间互相协调、互相配合,为用户提供最终价值。每个服务运行在其独立的进程中,服务与服务间采用轻量级的通信机制互相沟通(通常是基于 HTTP 协议的 RESTful API )。每个服务都围绕着具体业务进行构建,并且能够被独立的部署到生产环境、类生产环境等。另外,应当尽量避免统一的、集中式的服务管理机制,对具体的一个服务而言,应根据业务上下文,选择合适的语言、工具对其进行构建。

 

微服务架构关键1

是由服务组件组成的系统

  • 组件:可被独立替换和升级的软件单元

  • 组件间定义清晰、组件内与语言无关

  • 独立开发、独立测试、独立部署、独立扩展

按照业务而不是技术来组织服务

  • 面向业务,以减少跨团队协作与沟通

  • 跨功能团队(既管业务,又管数据)

  • 开发-运维一体的DevOps团队

 

微服务架构关键2

做全生命周期的产品而不是项目

  • 不是完成开发就交给运维的项目式

  • 组织形式谁开发、谁运营(You build, you run it.)

智能端点与通道扁平化

  • 强化终端而弱化通道

  • 组件间的通讯机制更加松耦合而高内聚

  • RESTful HTTP协议和仅提供消息路由功能的轻量级异步机制,是微服务架构常用通讯机制

 

微服务架构关键3

去中心化治理

  • 不必采用统一的语义与技术

  • 每个微服务可以考虑选用最佳工具去完成

去中心化数据管理

  • 分散存储与业务数据自治

  • 倡导多样性持久化,采用不同的技术存储

 

微服务架构关键4

自动化运维(DevOps)

自动化构建、自动化部署、弹性拓展

故障恢复与容错

熔断机制、自动化监控/告警、日志审计

演化式设计

不断地应对业务的变更

不断地适应技术的更迭

 

微服务架构的好处

  1. 简单、灵活、独立部署

  2. 专注、专业、高效、可靠、小团队

  3. 松耦合、高内聚、易拓展

  4. 语言、工具、无关

  • 是每个微服务组件都是简单灵活的,能够独立部署。应用不需要一个庞大的应用服务器来支撑。

  • 可以由一个小团队负责更专注专业,相应的也就更高效可靠。

  • 微服务之间是松耦合的,微服务内部是高内聚的,每个微服务很容易按需扩展。

  • 微服务架构与语言工具无关,自由选择合适的语言和工具,高效的完成业务目标即可。

 

微服务架构能带来的好处

解决传统单块风格(monolithic style)应用的问题

代码维护复杂

修改或新增代码,影响范围难以清晰估计

迭代周期很长,难以制定周期固定的迭代开发计划

对程序员的技能要求很高

测试困难

设计开发测试用例需要考虑的问题太多,包括验收测试、回归测试、性能测试

发布困难

可能需要停掉整个应用(或网站)

每次发布耗时很长:发布上百台服务器、预发布环境大量的回归测试..

对服务器硬件配置要求极高,垂直拓展困难

CPU、内存、硬盘、网络带宽......

无法做到无状态,水平扩展困难

无法实现线性水平扩展

难以做容量规划

 

解决集中式服务管理机制的问题

常见集中式服务管理机制

企业服务总线(ESB)

Dubbo的服务注册中心

配置中心

集中式服务管理机制的问题

可伸缩性差,容易成为性能瓶颈

有可能出现单点故障

设计开发难度极高,因为要保证非常高的可用性(HA)

 

解决重量级通信机制的问题

常见的重量级通信机制

基于HTTP的各种RPC(远程过程调用)风格协议:

SOAP/WSDL、XML-RPC、JSON-RPC、Burlap、Hessian

二进制Do (分布式对象)风格协议: Java RMI/EJB、.NET Remoting

重量级通信机制的问题

紧耦合:服务器端API做改动后,客户端必须同时做改动、同时部署

互操作性差:客户端与服务器端常常需要使用相同的编程语言

可伸缩性差:尤其是SOAP、XML-RPC

 

微服务的实践

微服务架构工作流程

  • 设计阶段

    • 将产品功能拆分为若干服务

    • 为每个服务设计 API 接口

  • 开发阶段

    • 实现 API 接口(包括单元测试)

    • 开发UI原型(页面)

  • 测试阶段

    • 前后端集成

    • 验证产品功能

  • 部署阶段

    • 发布测试环境

    • 发布生产环境

 

设计微服务架构需要掌握的基础知识

领域驱动设计(DDD)

RESTfulAPI的设计

以及深入理解HTTP协议

一种RESTfulAPI开发框架

Java: Spring MVC、Play、Jersey、RESTEasy、CXF

.NET: ASP.NET Web API

Node.js: Express、Seneca & PM2

Python: Django REST Framework、Flask

Ruby: Rails、Sinatra、Grape

 

微服务与DDD

英文名字:Domain Driven Design。

中文名字:领域驱动设计。

概述:DDD是一种以领域为核心的设计和开发理念。DDD通过维护—个深度反应领域概念的模型,以及提供了可行的经过实践检验的大量模式来应对领域的复杂性,偏向代码实现的(领域)对象。

领域模型既不是脱离代码实现的纯粹业务对象描述,更不是一—对应代码里的表或者对象。注意以下几点:

  1. 领域模型是精简的业务知识,所有权是业务代表而不是技术代表

  2. 领域模型的目的是构建业务需求和技术实现之间的桥梁,和传统的buttom-up软件开发模式相比,是种up-buttom自上而下的开发模式,可以避免需求偏离,因为一开始就是从业务需求出发去构建模型,再参照模型去实现。

  3. 领域模型是用来解构业务真实需求,可以理解成认识业务的一种方法论,领域模型的作用是构建一种共同语言,业务代表和技术代表在模型上沟通。

  4. 领域模型是不断迭代进化的,随需求迭代,业务变更而不断演进。

  5. 好的领域模型可以直接反应软件是做什么用的。

    • DDD是一种软件开发模式,目的是为了解构复杂的业务需求,降低不同工种间的沟通障碍,实顿结构清晰、可复用、易维护的软件

 

微服务与GRASP

GRASP是General ResponsibilityAssignment Software Patterns(通用职责分配软件模式)的简称,它的核心思想“职责分配”。

GRASP的主要特征

  • 对象职责分配的基本原则。

  • 主要应用在分析和建模上。

GRASP的核心思想

  • 自己干自己的事(职责的分配)

  • 自己干自己的能干的事(职责的分配)

如何把现实世界的业务功能抽象成对象,如何决定一个系统有多少对象,每个对象都包括什么职责,GRASP模式给出了最基本的指导原则

 

微服务与GRASP基本原则

信息专家

  • 给对象分配职责的基本原则是什么?

创建者

  • 假设系统中存在一个类A,那么在这个系统中,谁应该负责创建类A的新实例?

高内聚

  • 怎样保持对象是有重点的、可理解的、可管理的,并且能够支持低耦合?

低耦合

  • 怎样降低依赖性,减少变化带来的影响,提高重用性?

控制者

  • 在UI层之上首先接收和协调〔控制)系统操作的第一个对象是什么?

多态

  • 如何处理基于类型的选择?如何创建可插拔的软件构件?

纯虚构

  • 当你并不想违背高内聚和低耦合或其他目标,但是基于专家模式所提供的方案又不合适时,哪些对象应该承担这—职责?

间接性

  • 为了避免两个或多个事务之间直接耦合,应该如何分配职责?如何使对象解耦合,以支持低耦合并提高复用性潜力?

变化预防

  • 如何设计对象、子系统和系统.使其内部的变化或不稳定性不会对其他元素产生不良影响?

 

设计微服务架构需要掌握的可选知识

某种为部署微服务而设计的开发框架

Java: SpringBoot、Dropwizard

常用微服务运维工具

服务自动负载均衡

Consul

Eureka:基于AWS的服务负载均衡

Nginx

HAProxy

日志、监控

ELK: Elasticsearch/Logstash/Kibana

Zabbix

基于Docker的部署和服务编排

 

微服务主要技术——dubbo

Dubbo(开源分布式服务框架),阿里巴巴公司开源的一个高性能优秀的服务框架,使得应用可通过高性能的RPC 实现服务的输出和输入功能

主要核心部件:

Remoting:网络通信框架,实现了sync-over-async 和 Logo request-response 消息机制.

RPC:一个远程过程调用的抽象,支持负载均衡、容灾和集群功能

Registry:服务目录框架用于服务的注册和服务事件发布和订阅

 

微服务主要技术——Spring Cloud

Spring Cloud是一系列框架的有序集合:

  • 利用 Spring Boot 的开发便利性,简化了分布式系统基础设施的开发。

  • Spring Cloud Eureka 是 Spring Cloud Netflix 的一部分,它基于 NetflixEureka 做了二次封装,完成微服务架构中的服务治理功能

  • Spring Cloud Netflix 是对 Netflix 分布式服务开发框架的封装,包括服务发现和注册、负载均衡、断路器、REST客户端、请求路由等

  • Spring Cloud Zookeeper 对 Zookeeper 的封装,使之能配合其它 SpringCloud 项目使用,一般当作注册中心

  • Spring Cloud Bus 分布式消息队列,是对 Kafka MQ 的封装,实现可靠消息

  • Spring Cloud Config 将配置信息中央化保存

  • Spring Cloud Security对Spring Security的封装,实现服务安全等

 

微服务主要技术——docker

Docker 是一个开源的应用容器引擎,让开发者可以打包它们的应用以及依赖包到一个可移植的容器中,然后发布到任何一个流行的 Linux 机器上,也可以实现虚拟化,容器是完全使用沙箱机制,相互之间不会有任何接口。

Docker通常用于如下场景:

  • 使应用的打包与部署自动化

  • 创建轻量、私密的PAAS环境

  • 实现自动化测试和持续的集成/部署

  • 部署与扩展webapp、数据库和后台服务

微服务主要技术——jenkins

Jenkins是一个开源软件项目,是基于Java开发的一种持续集成工具,用于监控持续重复的工作,旨在提供一个开放易用的软件平台,使软件的持续集成变成可能。

Jenkins功能包括:

  1. 持续的软件版本发布/测试项目

  2. 监控外部调用执行的工作

 

微服务应用平台总体架构

开发集成:微服务平台需要具备的一些工具和仓库。

运行时:微服务平台的基础能力和分布式的支撑能力,微服务运行容器运行在这个平台之上。

监控治理:对受管的微服务进行统一的监控、配置等能力。

服务网关:负责与前端的WEB应用移动APP等渠道集成,对前端请求进行认真鉴权,然后路由转发。

 

微服务应用平台运行架构

 

划分服务的原则是什么

  • 参考DDD中的设计策略“界定的上下文”(BoundedContext) ,划分出系统中不同的领域模型(上下文)

  • 每一个领域模型拥有自己独立的数据库(或其他持久存储)

  • DDD中其他对于划分服务有参考价值的设计策略

    • 上下文映射(Context Map)

    • 共享内核(Shared Kernel)

    • 客户-供应商(Customer-Supplier)

    • 顺从者(Conformist)

    • 防崩溃层(Anticorruption Layer)

    • 隔离通道(Separate Way)

    • 开放主机服务(Open Host Service)

 

微服务应用设计原则

 

 

 

 

 

 

服务之间选择何种轻量级的通信协议

  • API的实现技术应该避免产生与客户端的耦合

    • 例如Java RMI,要求客户端必须使用Java语言,耦合很强

    • 应该选择与具体技术不相关的API实现方式,以保证技术的选择不被限制

  • 普通场合应优先选择基于HTTP的RESTful API

    • 基于HTTP协议,互操作性好,各种编程语言都支持

    • 可伸缩性好

    • 松耦合

    • 易于测试

    • 易于形成统一的编程风格

 

如何确定使用何种服务编程语言

  • 优先选择团队原先掌握的编程语言

  • 选择另外—种互补性强的编程语言

    • Java/C# 与Node.js/Python/Ruby/Go

  • 根据对性能的要求

    • ·性能要求高:Java/C#/Node.js/Go

    • 性能要求不高::Python/Ruby

  • 根据业务逻辑的变化频繁程度

    • 业务逻辑相对固定:Java/C#

    • 业务逻辑可能经常变化: Node.js/Python/Ruby

 

如何做到服务的独立部署

  • 尽量减少服务之间的依赖

    • 服务功能做到高内聚

  • API设计做到松耦合

    • 基于通用的通信机制,首选基于HTTP的RESTful API

    • 服务API可做的独立修改

      • 可自由添加非必需的请求参数

      • 可自由修改请求参数的类型

      • 可自由添加响应参数

      • 可自由添加错误代码

      • 可通过超文本通知客户端相关联的资源

    • 通过服务版本号控制不兼容的修改

 

如何做到服务的去中心化

  • 不使用集中式的企业服务总线或服务注册中心

    • 通过域名+URL来暴露服务

    • 使用Consul+DNS来做服务发现和自动负载均衡

  • 不使用集中式的配置中心

    • 配置信息由每个服务自行管理

  • 案例分析: 2010年淘宝网的配置中心服务

 

如何解决大量微服务引入的运维成本

  • 能自动化的地方一定尽量自动化

    • 发布自动化

    • 测试自动化

      • 验收测试、回归测试、性能测试

    • 负载均衡自动化

    • 扩容、缩容自动化

    • 监控自动化

  • 基于Docker容器部暑

  • 基于云计算平台部署

 

基于Docker容器部署带来的好处

  • 可以提高部署的自动化程度

    • 缩短部署时间,达到秒级部署

  • 可以提高测试环境与生产环境的一致性

    • 在测试环境中测出尽量多与环境有关的bug

  • 可以提高服务器硬件资源的利用效率

  • 可以实现自动化扩容、缩容

 

基于云计算平台部署带来的好处

  • 可以带来更好的可伸缩性

    • 水平扩展、垂直扩展都更容易

  • 可以带来更好的容错性

  • 可以很容易地添加各种新的能力

    • 例如阿里云所支持的大数据分析工具

  • 可以大幅降低运维的成本

    • 与应用无关的系统级运维,由云计算平台运营商负责

    • 应用的运维团队只需关注与应用本身相关的运维

 

其它

微服务带来的问题

  1. 依赖接口服务

    • 服务接口如何管理

    • 接口变更跟踪难

    • 依赖服务调试麻烦

  2. 部分模块重复构建

    • 安全认证

    • 配置日志

  3. 分布式带来的问题

    • 分布式事务问题

    • 依赖服务不稳定

    • 需要引入异步模式

  4. 运维复杂度徒增

    • 部署物数量倍增

    • 监控进程倍增

    • 故障定位难

    • 问题追溯难

 

关键问题——服务注册和路由

 

 

服务在启动的时候,会将自己要发布的服务注册到服务注册中心,运行时,如果需要调用其他微服务的接口,本地缓存或到注册中心获取服务提供者的地址,获得地址后,通过微服务容器内部的负载均衡进行路由调用。

 

关键问题——同步调用

 

 

SEDA : staged event-driven architecture本质上就是采用分布式事件驱动的模式,用异步模拟来同步,无阻塞等待,再加上资源分配隔离结起来的一个解决方案。

 

队列分三个阶段,每个阶段对应每个操作,router有个队列维持同步调用的事件信息

 

微服务系统的团队管理

  • 康威定律(Conway's Law)

    • 任何组织在设计一套系统(广义概念上的系统)时,所交付的设计方案在结构来说,都会与该组织的沟通结构保持一致。

  • 必须有整体的规划和相关规范

    • 划分界定的上下文

    • 根据界定的上下文划分服务

    • 制定并维护服务设计规范、监控规范

  • 团队组织应与划分的领域模型(上下文)匹配

    • 产品设计团队

    • 开发团队

    • 测试团队

  • 充分授权

    • 让小团队完全拥有某个领域模型及其上服务的所有权

    • 所有权涵盖需求、构建、部署、运维等服务的全生命周期

posted @   小gun  阅读(306)  评论(0编辑  收藏  举报
努力加载评论中...
点击右上角即可分享
微信分享提示