微服务架构的前世今生

标签：rem   stat   不用   zookeeper   完整   关系   持续交付   方法   abi   

　　随着互联网的发展，网站应用的规模不断扩大，常规的垂直应用架构已无法应对，分布式服务架构以及流动计算架构势在必行，亟需一个治理系统确保架构有条不紊的演进。

• 单一应用架构

  • 当网站流量很小时，只需一个应用，将所有功能都部署在一起，以减少部署节点和成本。
  • 此时，用于简化增删改查工作量的 数据访问框架(ORM) 是关键。
  • 缺点：随着应用功能的增多，代码量越来越大，越来越难维护，那怎么解决代码一体化的问题？

• 垂直应用架构

  • 当访问量逐渐增大，单一应用增加机器带来的加速度越来越小，将应用拆成互不相干的几个应用，以提升效率。
  • 此时，用于加速前端页面开发的 Web框架(MVC) 是关键。
  • 缺点：垂直架构中相同逻辑代码需要不断的复制，不能复用。每个垂直模块都相当于一个独立的系统。

• 分布式服务架构

  • 当垂直应用越来越多，应用之间交互不可避免，将核心业务抽取出来，作为独立的服务，逐渐形成稳定的服务中心，使前端应用能更快速的响应多变的市场需求。
  • 此时，用于提高业务复用及整合的 分布式服务框架(RPC) 是关键。
  • 缺点：服务越来越多，需要管理每个服务的地址，调用关系错综复杂，难以理清依赖关系，服务状态难以管理，无法根据服务情况动态管理。

• 流动计算架构

  • 当服务越来越多，容量的评估，小服务资源的浪费等问题逐渐显现，此时需增加一个调度中心基于访问压力实时管理集群容量，提高集群利用率。
  • 此时，用于提高机器利用率的 资源调度和治理中心(SOA) 是关键。
  • 缺点：服务间会有依赖关系，一旦某个环节出错会影响较大，服务关系复杂，运维、测试部署困难，不符合DevOps思想。

• 微服务架构：

• 单一职责：微服务中每一个服务都对应唯一的业务能力，做到单一职责

  • 微：微服务的服务拆分粒度很小，例如一个用户管理就可以作为一个服务。每个服务虽小，但“五脏俱全”。

• 面向服务：面向服务是说每个服务都要对外暴露服务接口API。并不关心服务的技术实现，做到与平台和语言无关，也不限定用什么技术实现，只要提供 Rest 的接口即可。

• 自治：自治是说服务间互相独立，互不干扰

  • 团队独立：每个服务都是一个独立的开发团队，人数不能过多。
    • 技术独立：因为是面向服务，提供 Rest 接口，使用什么技术没有别人干涉。
    • 前后端分离：采用前后端分离开发，提供统一 Rest 接口，后端不用再为 PC、移动端开发不同接口。
    • 数据库分离：每个服务都使用自己的数据源
    • 部署独立，服务间虽然有调用，但要做到服务重启不影响其它服务。有利于持续集成和持续交付。每个服务都是独立的组件，可复用，可替换，降低耦合，易维护 Docker 部署服务

2|0什么是微服务

　　Martin Fowler 是这样解释微服务概念的：

　　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资源API）进行通信。 这些服务是围绕业务功能构建的，可以通过全自动部署机制独立部署。 这些服务的集中管理最少，可以用不同的编程语言编写，并使用不同的数据存储技术。

　　微服务就是将一个单体架构的应用按业务划分为一个个的独立运行的程序即服务，它们之间通过 HTTP 协议进行通信（也可以采用消息队列来通信，如 RabbitMQ，Kafaka 等），可以采用不同的编程语言，使用不同的存储技术，自动化部署（如 Jenkins）减少人为控制，降低出错概率。服务数量越多，管理起来越复杂，因此采用集中化管理。例如 Eureka，Zookeeper 等都是比较常见的服务集中化管理框架。

　　微服务是一种架构风格。一个大型的复杂软件应用，由一个或多个微服务组成。系统中的各个微服务可被独立部署，各个微服务之间是松耦合的。每个微服务仅关注于完成一件任务并很好的完成该任务。

2|1优点

• 测试容易
• 可伸缩性强
• 可靠性强
• 跨语言
• 协同开发
• 方便系统迭代

2|2缺点

• 运维成本高，部署项目多
• 接口兼容版本问题
• 分布式系统的复杂性
• 分布式事务

3|0SOA vs MicroServices

　　面向服务架构（SOA）是一种用于设计软件的伟大原则。在SOA中，所有组件都是独立自主的，并能为其他组件提供服务。大体上，SOA与微服务架构是非常相像的。那么它们之间的区别到底是什么呢？微服务是细粒度的SOA组件。换句话说，某单个SOA组件可以被拆成多个微服务，而这些微服务通过分工协作，可以提供与原SOA组件相同级别的功能，如下图所示。

　　微服务是细粒度的SOA组件，它们是关注点更窄的轻量级服务。微服务推崇执行的标准（例如HTTP）是人们广泛了解并共同使用的。我们可以通过选择合适的语言或工具来构建某个组件（微服务），除了技术栈与服务规模之外，在SOA与微服务之间还有一个更大的区别：领域模型。在一个基于微服务的软件中，每个微服务应该在本地存储自身管理的数据，并将领域模型分别隔离到单个服务中。而在面向SOA的软件中，数据往往存储在单个大型的数据库中，服务之间会共享领域模型。

一句话总结：微服务是 SOA 发展出来的产物，它是一种比较现代化的细粒度的 SOA 实现方式。

4|0Dubbo vs Spring Cloud

• Spring 全家桶
  用起来很舒服，只有你想不到，没有它做不到。
• Dubbo
  很多国内的企业还在用，可以支持 RESTful 风格的 API，调用远程 API 像调用本地 API 一样，同时其基于接口的方式增加了服务间的耦合。

总结

• Dubbo 由于是二进制的传输，占用带宽会更少
• SpringCloud 是 http 协议传输，带宽会比较多，同时使用 http 协议一般会使用 JSON 报文，消耗会更大
• Dubbo 的开发难度较大，原因是 Dubbo 的 jar 包依赖问题很多大型工程无法解决
• SpringCloud 的接口协议约定比较自由且松散，需要有强有力的行政措施来限制接口无序升级
• Dubbo 的注册中心可以选择 ZooKeeper Redis 等多种，SpringCloud 的注册中心只能用 eureka 或者自研
• 从系统结构简易程序：SpringCloud 的系统结构更简单、“注册 + SpringMvc = SpringCloud”，而 Dubbo 各种复杂的 url，protocol，register，invocation，dubbofilter，dubboSPI，dubbo序列化..........炫技的成分更多一些
• 从性能：Dubbo 的网络消耗小于 SpringCloud，但是在国内 95% 的公司内，网络消耗不是什么太大问题，如果真的成了问题，通过压缩、二进制、高速缓存、分段降级等方法，很容易解决。

5|0微服务设计原则

5|1AKF 拆分原则

　　业界对于可扩展的系统架构设计有一个朴素的理念，就是：通过加机器可以解决容量和可用性问题（如果一台不行就两台）。

　　用个段子描述就是：世界上没有什么事是一顿烧烤解决不了的，如果有，那就两顿。

　　这一理念在“云计算”概念疯狂流行的今天。得到了广泛的认可。对于一个规模迅速增长的系统而言。容量和性能问题当然是首当其冲的。但是随着时间的向前，系统规模的增长，除了面对性能与容量的问题外，还需要面对功能与模块数量上增长带来的系统复杂性问题。以及业务变化带来的提供差异化服务问题。而许多系统在架构设计时并未充分考虑到这些问题，导致系统的重构成为常态。从而影响业务交付能力，还浪费人力财力。对此《The Art of Scalability》一书提出了一个更加系统的可扩展模型——AKF 可扩展立方。这个立方体中沿着三个坐标轴设置分别为 X，Y，Z。

　　一个叫 AKF 的公司的技术专家抽象总结的应用扩展的三个维度。理论上按照这三个扩展模式，可以将一个单体系统，进行无限扩展。

• X 轴：指的是水平复制，很好理解，就是讲单体系统多运行几个实例，成为集群加负载均衡的模式。
• Z 轴：是基于类似的数据分区，比如一个互联网打车应用突然火了，用户量激增，集群模式撑不住了，那就按照用户请求的地区进行数据分区，北京、上海、四川等多建几个集群。
• Y 轴：就是我们所说的微服务的拆分模式，就是基于不同的业务拆分。

　　场景说明：比如打车应用，一个集群撑不住时，分了多个集群，后来用户激增还是不够用，经过分析发现是乘客和车主访问量很大，就将打车应用拆成了三个，分别为乘客服务、车主服务、支付服务。三个服务的业务特点各不相同，独立维护，各自都可以再次按需扩展。

5|2前后端分离原则

• 前后端技术分离，可以由各自的专家来对各自的领域进行优化，这样前端的用户体验优化效果更好。
• 前后端分离模式下，前后端交互界面更清晰，就剩下了接口模型，后端的接口简洁明了，更容易维护。
• 前端多渠道集成场景更容易实现，后端服务无需变更，采用统一的数据和模型，可以支持多个前端：例如：微信 h5 前端、PC 前端、安卓前端、IOS 前端。

5|3无状态服务

　　对于无状态服务，首先说一下什么是状态：如果一个数据需要被多个服务共享，才能完成一笔交易，那么这个数据被称为状态。进而依赖这个“状态”数据的服务被称为有状态服务，反之称为无状态服务。那么这个无状态服务原则并不是说在微服务架构里就不允许存在状态，表达的真实意思是要把有状态的业务服务改变为无状态的计算类服务，那么状态数据也就相应的迁移到对应的“有状态数据服务”中。场景说明：例如我们以前在本地内存中建立的数据缓存、Session 缓存，到现在的微服务架构中就应该把这些数据迁移到分布式缓存中存储，让业务服务变成一个无状态的计算节点。迁移后，就可以做到按需动态伸缩，微服务应用在运行时动态增删节点，就不再需要考虑缓存数据如何同步的问题。

　　也就是对同一个 url 请求没有上下文关系。举个生活中的例子：

　　比如空调遥控器，你按上下调整温度时，空调温度设定值会变化，遥控器信号到空调是单向传输。现在空调显示温度 20 度，遥控器 20 度。如果遥控器与空调之间是有状态的，假设你离开空调接收范围调整了遥控器温度，变成 19，那回到范围内你按一次升高一度，基于原先温度状态，遥控器给空调发送一个“提高1度”的指令，就会出现遥控器提高到 20，而空调变成21。如果要空间与空调之前是无状态的，假设你离开空调接收范围调整了遥控器温度，变成 19，那回到范围内你按一次升高一度，遥控器给空调发送一个“设定温度值20”，这样两者最终还是相同的值。

5|4Restful 通信风格

　　基于无状态通信原则，在这里我们直接推荐一个实践优选的 Restful 通信风格 ，因为他有很多好处：

• 无状态协议 HTTP，具备先天优势，扩展能力很强。例如需要安全加密时，有现成的成熟方案 HTTPS 可用。
• JSON 报文序列化，轻量简单，人与机器均可读，学习成本低，搜索引擎友好。
• 语言无关，各大热门语言都提供成熟的 Restful API 框架，相对其他的一些 RPC 框架生态更完善。

6|0微服务架构常见概念

6|1服务治理

　　服务治理就是进行服务的自动化管理，其核心是服务的自动注册与发现。

• 服务注册：服务实例将自身服务信息注册到注册中心。
• 服务发现：服务实例通过注册中心，获取注册到其中的服务实例的信息，通过这些信息去请求它们提供的服务。
• 服务剔除：服务注册中心将出问题的服务自动剔除到可用列表之外，使其不会被调用到。

6|2服务调用

　　在微服务架构中，通常存在多个服务之间的远程调用的需求。目前主流的远程调用技术有基于 HTTP 的 RESTful 接口和基于 TCP 的 RPC 协议。

• REST（Representational State Transfer）：一种 HTTP 调用的格式，更标准，更通用，无论哪种语言都支持 http 协议。
• RPC（Remote Promote Call）：一种进程间通信方式，允许像调用本地服务一样调用远程服务。RPC 框架的主要目标就是让远程服务调用更简单、透明。RPC 框架负责屏蔽底层的传输方式、序列化方式和通信细节。开发人员在使用的时候只需要了解谁在什么位置提供了什么样的远程服务接口即可，并不需要关心底层通信细节和调用过程。

6|3服务网关

　　随着微服务的不断增多，不同的微服务一般会有不同的网络地址，而外部客户端可能需要调用多个服务的接口才能完成一个业务需求，如果让客户端直接与各个微服务通信可能出现：

• 客户端会多次请求不同的微服务，增加了客户端的复杂性
• 存在跨域请求，在一定场景下处理相对复杂
• 身份认证问题，每个微服务需要独立身份认证
• 难以重构，随着项目的迭代，可能需要重新划分微服务
• 某些微服务可能使用了防火墙/浏览器不友好的协议，直接访问会有一定的困难

　　针对这些问题，API网关顺势而生。

　　API 网关直面意思是将所有 API 调用统一接入到 API 网关层，由网关层统一接入和输出。一个网关的基本功能有：统一接入、安全防护、协议适配、流量管控、长短链接支持、容错能力。有了网关之后，各个 API 服务提供团队可以专注于自己的的业务逻辑处理，而 API 网关更专注于安全、流量、路由等问题。

6|4服务容错

　　在微服务中，一个请求经常会涉及到调用多个服务，如果其中某个服务不可用，没有做服务容错的话，极有可能会造成一连串的服务不可用，这就是雪崩效应。最终的结果就是：一个服务不可用，导致一系列服务的不可用。

　　造成雪崩的原因可以归结为以下三点：

• 服务提供者不可用（硬件故障，程序 BUG，缓存击穿，用户大量请求等）
• 重试加大流量（用户重试，代码逻辑重试）
• 服务消费者不可用（同步等待造成的资源耗尽）

　　我们没法预防雪崩效应的发生，只能尽可能去做好容错。服务容错的三个核心思想是：

• 不被外界环境影响
• 不被上游请求压垮
• 不被下游响应拖垮

6|5链路追踪

　　随着微服务架构的流行，服务按照不同的维度进行拆分，一次请求往往需要涉及到多个服务。互联网应用构建在不同的软件模块集上，这些软件模块，有可能是由不同的团队开发、可能使用不同的编程语言来实现、有可能布在了几千台服务器，横跨多个不同的数据中心。因此，就需要对一次请求涉及的多个服务链路进行日志记录，性能监控等等。单纯的理解链路追踪，就是指一次任务的开始到结束，期间调用的所有系统及耗时（时间跨度）都可以完整记录下来。

　　链路追踪系统做好了，链路数据有了，借助前端解析和渲染工具，可以达到下图中的效果：

6|6配置中心

　　配置文件是我们再熟悉不过的，在微服务系统中，每个微服务不仅仅只有代码，还需要连接其他资源，例如数据库的配置或功能性的开关 MySQL、Redis 、Security 等相关的配置。除了项目运行的基础配置之外，还有一些配置是与我们业务有关系的，比如说七牛存储、短信和邮件相关，或者一些业务上的开关。

　　但是随着微服务系统的不断迭代，整个微服务系统可能会成为一个网状结构，这个时候就要考虑整个微服务系统的扩展性、伸缩性、耦合性等等。其中一个很重要的环节就是配置管理的问题。

　　常规配置管理解决方案缺点：

• 硬编码（需要修改代码、繁琐、风险大）
• properties 或者 yml（集群环境下需要替换和重启）
• xml（重新打包和重启）

　　由于常规配置管理有很大的缺点，所以采用 Spring Cloud Config 或 Consul 或 Apollo 或 Nacos 等配置中心集中式的来管理每个服务的配置信息。

　　至此微服务架构介绍所有的知识点就讲解结束了。

微服务架构的前世今生

标签：rem   stat   不用   zookeeper   完整   关系   持续交付   方法   abi   

原文地址：https://www.cnblogs.com/youngdeng/p/12924650.html