微服务请求get编码 微服务

                                                                微服务的介绍

1.1系统架构演变

随着互联网的发展，网站应用的规模也在不断的扩大，进而导致系统架构也在不断的进行变化。 从互联网早起到现在，系统架构大体经历了下面几个过程: 单体应用架构--->垂直应用架构--->分布式架构--->SOA架构--->微服务架构，当然还有悄然兴起的Service Mesh(服务网格化)。

接下来我们就来了解一下每种系统架构是什么样子的， 以及各有什么优缺点。

1.1.1 单体应用架构

互联网早期，一般的网站应用流量较小，只需一个应用，将所有功能代码都部署在一起就可以，这样可以减少开发、部署和维护的成本。

比如说一个电商系统，里面会包含很多用户管理，商品管理，订单管理，物流管理等等很多模块，  我们会把它们做成一个web项目，然后部署到一台tomcat服务器上。

优点：

1. 项目架构简单，小型项目的话，开发成本低。
2. 项目部署在一个节点上，维护方便

缺点：

1. 全部功能集成在一个工程中，对于大型项目来讲不易开发和维护[修改代码]。
2. 项目模块之间紧密耦合，单点容错率低。
3. 无法针对不同模块进行针对性优化和水平扩展

1.1.2 垂直应用架构

随着访问量的逐渐增大，单一应用只能依靠增加节点来应对，但是这时候会发现并不是所有的模块 都会有比较大的访问量.

还是以上面的电商为例子， 用户访问量的增加可能影响的只是用户和订单模块， 但是对消息模块的影响就比较小. 那么此时我们希望只多增加几个订单模块， 而不增加消息模块.  此时单体应用就做不到了， 垂直应用就应运而生了.

所谓的垂直应用架构，就是将原来的一个应用拆成互不相干的几个应用，以提升效率。比如我们可  以将上面电商的单体应用拆分成:

电商系统(用户管理 商品管理 订单管理)

后台系统(用户管理 订单管理 客户管理)

CMS系统(广告管理 营销管理) 

这样拆分完毕之后，一旦用户访问量变大，只需要增加电商系统的节点就可以了，而无需增加后台 和CMS的节点。建立三个工程。

 缺点：

1. 系统拆分实现了流量分担，解决了并发问题，可以针对不同模块进行优化和水平扩展
2. 一个系统的问题不会影响到其他系统，提高容错率

优点：

1. 系统之间相互独立， 无法进行相互调用
2. 系统之间相互独立， 会有重复的开发任务

1.1.3 分布式架构

当垂直应用越来越多，重复的业务代码就会越来越多。这时候，我们就思考可不可以将重复的代码 抽取出来，做成统一的业务层作为独立的服务（service），然后由前端控制层(controller)调用不同的业务层服务呢？

这就产生了新的分布式系统架构。它将把工程拆分成表现层controller和服务层service两个部分，服务层中包含业务  逻辑。表现层只需要处理和页面的交互，业务逻辑都是调用服务层的服务来实现。

 缺点：

1. 调用关系错综复杂，难以维护

优点：

1. 抽取公共的功能为服务层，提高代码复用性

1.1.4 SOA架构----阿里dubbo

在分布式架构下，当服务越来越多，容量的评估，小服务资源的浪费等问题逐渐显现，此时需增加一个调度中心对集群进行实时管理。此时，用于资源调度和治理中心(SOA Service Oriented Architecture，面向服务的架构)是关键。

 优点：

1. 使用注册中心解决了服务间调用关系的自动调节

缺点：

1. 服务间会有依赖关系，一旦某个环节出错会影响较大( 服务雪崩 )
2. 服务关系复杂，运维、测试部署困难。

1.1.5 微服务架构

微服务架构在某种程度上是面向服务的架构SOA继续发展的下一步，它更加强调服务的"彻底拆分"---->必须要springboot(独立的系统) 必须依赖于springboot技术。Springcloud如果没有springboot 那么springcloud也无法使用。 springboot可以独立使用。因为springboot里面内置了tomcat   独立运行。Java -jar xxx.jar

只适合大工程。移动互联网 电商项目 p2p 等，

系统管理--->系统微服务   入库管理 -----入库微服务

优点：

1. 服务原子化拆分，独立打包、部署和升级，保证每个微服务清晰的任务划分，利于扩展
2. 微服务之间采用Restful等轻量级http协议相互调用

缺点：  --->  小型项目----微服务架构不合适。仓库系统---微服务。

1. 微服务系统开发的技术成本高《高》（容错、分布式事务等）

1.2 微服务架构简介

微服务架构， 简单的说就是将单体应用进一步拆分，拆分成更小的服务，每个服务都是一个可以独立运行的项目。

1.2.1 微服务架构常见的问题

针对每个问题使用不同的组件来讲解。

一旦采用微服务系统架构，就势必会遇到这样几个问题：

1. 这么多小服务，如何管理他们？   
2. 这么多小服务，他们之间如何通讯？调用
3. 这么多小服务，客户端怎么访问他们？前端
4. 这么多小服务，一旦出现问题了，应该如何自处理？
5. 这么多小服务，一旦出现问题了，应该如何排错?

Springcloud微服务就是针对上面这些问题 提出的解决方案。

对于上面的问题，是任何一个微服务设计者都不能绕过去的，因此大部分的微服务产品都针对每一个问题提供了相应的组件来解决它们。---学习如何解决上面的问题==组件。

1.2.2 微服务架构的常见概念 

1.2.2.1 服务治理

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

服务注册：服务实例将自身服务信息注册到注册中心。

服务发现：服务实例通过注册中心，获取到注册到其中的服务实例的信息，通过这些信息去请求它们提供的服务。

服务剔除：服务注册中心将出问题的服务自动剔除到可用列表之外，使其不会被调用到。

1.2.2.2 服务调用 

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

REST(Representational State Transfer)

这是一种HTTP调用的格式，更标准，更通用，无论哪种语言都支持http协议。  

RPC（Remote Promote Call）

Rpc  @Autowire Bservice  bservice.方法（）

一种进程间通信方式。允许像调用本地服务一样调用远程服务。RPC框架的主要目标就是让远程服务调用更简单、透明。RPC框架负责屏蔽底层的传输方式、序列化方式和通信细节。开发人员在使用的时候只需要了解谁在什么位置提供了什么样的远程服务接口即可，并不需要关心底层通信细节和调用过程。

1.2.2.3 服务网关

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

1. 客户端需要调用不同的url地址，增加难度
2. 在一定的场景下，存在跨域请求的问题
3. 每个微服务都需要进行单独的身份认证

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

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

1.2.2.4 服务容错

 

雪崩效应。

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

1. 不被外界环境影响
2. 不被上游请求压垮
3. 不被下游响应拖垮

1.2.2.5 链路追踪

        随着微服务架构的流行，服务按照不同的维度进行拆分，一次请求往往需要涉及到多个服务。互联网应用构建在不同的软件模块集上，这些软件模块，有可能是由不同的团队开发、可能使用不同的编程语言来实现、有可能布在了几千台服务器，横跨多个不同的数据中心。

因此，就需要对一次请求涉及的多个服务链路进行日志记录，性能监控即链路追踪

1.2.3 微服务架构常见的解决方案

 1.2.3.1 ServiceComb

Apache ServiceComb，前身是华为云的微服务引擎 CSE (Cloud Service Engine) 云服务，是全球首个Apache微服务顶级项目。它提供了一站式的微服务开源解决方案，致力于帮助企业、用户和开发者将企业应用轻松微服务化上云，并实现对微服务应用的高效运维管理.

 1.2.3.2 SpringCloud（SpringCloud很多的组件都是拿的是Netflix公司，这家公司的这些组件停止维护和更新了）

一系列框架的集合。它利用Spring Boot的开发便利性巧妙地简化了分布式系统基础设施的开发，如服务发现注册、配置中心、消息总线、负载均衡、断路器、数据监控等，都可以用Spring Boot的开发风格做到一键启动和部署。

        Spring Cloud并没有重复制造轮子，它只是将目前各家公司开发的比较成熟、经得起实际考验的服务框架组合起来，通过Spring Boot风格进行再封装屏蔽掉了复杂的配置和实现原理，最终给开发者留出了一套简单易懂、易部署和易维护的分布式系统开发工具包。

已经停更了。Euruka(注册中),feign远程调用,hystrix 容错,zuul网关        

 1.2.3.3 SpringCloud Alibaba（引入springcloud很多组件都更新了）

        Spring Cloud Alibaba 致力于提供微服务开发的一站式解决方案。此项目包含开发分布式应用微服务的必需组件，方便开发者通过 Spring Cloud 编程模型轻松使用这些组件来开发分布式应用服务。

 1.3 SpringCloud Alibaba介绍

        Spring Cloud Alibaba 致力于提供微服务开发的一站式解决方案。此项目包含开发分布式应用微服务的必需组件，方便开发者通过 Spring Cloud 编程模型轻松使用这些组件来开发分布式应用服务。

        依托 Spring Cloud Alibaba，您只需要添加一些注解和少量配置，就可以将 Spring Cloud 应用接入阿里微服务解决方案，通过阿里中间件来迅速搭建分布式应用系统。

1.3.1 主要功能

服务限流降级：默认支持 WebServlet、WebFlux， OpenFeign、RestTemplate、Spring Cloud

Gateway， Zuul， Dubbo 和 RocketMQ 限流降级功能的接入，可以在运行时通过控制台实时修

改限流降级规则，还支持查看限流降级 Metrics 监控。

服务注册与发现：适配 Spring Cloud 服务注册与发现标准nacos，默认集成了 Ribbon 的支持。

分布式配置管理：支持分布式系统中的外部化配置，配置更改时自动刷新。

消息驱动能力：基于 Spring Cloud Stream 为微服务应用构建消息驱动能力。

分布式事务：使用 @GlobalTransactional 注解， 高效并且对业务零侵入地解决分布式事务问题。

阿里云对象存储：阿里云提供的海量、安全、低成本、高可靠的云存储服务。支持在任何应用、任

何时间、任何地点存储和访问任意类型的数据。

分布式任务调度：提供秒级、精准、高可靠、高可用的定时（基于 Cron 表达式）任务调度服务。

同时提供分布式的任务执行模型，如网格任务。网格任务支持海量子任务均匀分配到所有

Worker（schedulerx-client）上执行。

阿里云短信服务：覆盖全球的短信服务，友好、高效、智能的互联化通讯能力，帮助企业迅速搭建

客户触达通道。

1.3.2 组件

Sentinel：把流量作为切入点，从流量控制、熔断降级、系统负载保护等多个维度保护服务的稳

定性。

Nacos：一个更易于构建云原生应用的动态服务发现、配置管理和服务管理平台。

RocketMQ：一款开源的分布式消息系统，基于高可用分布式集群技术，提供低延时的、高可靠

的消息发布与订阅服务。

Dubbo：Apache Dubbo™ 是一款高性能 Java RPC 框架。

Seata：阿里巴巴开源产品，一个易于使用的高性能微服务分布式事务解决方案。

Alibaba Cloud ACM：一款在分布式架构环境中对应用配置进行集中管理和推送的应用配置中心

产品。

Alibaba Cloud OSS: 阿里云对象存储服务（Object Storage Service，简称 OSS），是阿里云提

供的海量、安全、低成本、高可靠的云存储服务。您可以在任何应用、任何时间、任何地点存储和

访问任意类型的数据。

Alibaba Cloud SchedulerX: 阿里中间件团队开发的一款分布式任务调度产品，提供秒级、精

准、高可靠、高可用的定时（基于 Cron 表达式）任务调度服务。

Alibaba Cloud SMS: 覆盖全球的短信服务，友好、高效、智能的互联化通讯能力，帮助企业迅速

搭建客户触达通道。

1.3.3 微服务拆分的原则

之前你维护的一体化架构就像是一个大的蜘蛛网，不同功能模块错综复杂地交织在一起，方法之间调用关系非常的复杂，导致你修复了一个 Bug 可能会引起另外多个 Bug，整体的维护成本非常高。同时，数据库较弱的扩展性也限制了服务的扩展能力

出于上述考虑，你要对架构做拆分。但拆分并不像听上去那么简单，这其实就是将整体工程重构甚至重写的过程。你需要将代码拆分到若干个子工程里面，再将这些子工程通过一些通信方式组装起来，这对架构是很大的调整，需要跨多个团队协作完成。

所以在开始拆分之前你需要明确几个拆分的原则，否则就会事倍功半甚至对整体项目产生不利的影响。

         原则一，做到单一服务内部功能的高内聚和低耦合。

也就是说每个服务只完成自己职责之内的任务，对于不是自己职责的功能交给其它服务来完成。说起来你可能觉得理所当然对这一点不屑一顾，但很多人在实际开发中，经常会出现一些问题。

比如，我之前的项目中有用户服务和内容服务，用户信息中有“是否为认证用户”字段。组内有个同事在内容服务里有这么一段逻辑：如果用户认证字段等于 1，代表是认证用户，那么就把内容权重提升。问题是判断用户是否为认证用户的逻辑应该内聚在用户服务内部，而不应该由内容服务判断，否则认证的逻辑一旦变更内容服务也需要一同跟着变更，这就不满足高内聚、低耦合的要求了。所幸我们在 Review 代码时及时发现了这个问题，并在服务上线之前修复了它。

           原则二，你需要关注服务拆分的粒度，先粗略拆分再逐渐细化。

在服务拆分的初期，你其实很难确定服务究竟要拆分成什么样。但是从“微服务”这几个字来看，服务的粒度貌似应该足够小，甚至有“一方法一服务”的说法。不过服务多了也会带来问题，像是服务个数的增加会增加运维的成本。再比如原本一次请求只需要调用进程内的多个方法，现在则需要跨网络调用多个 RPC 服务，在性能上肯定会有所下降。

所以我推荐的做法是：拆分初期可以把服务粒度拆得粗一些，后面随着团队对于业务和微服务理解的加深，再考虑把服务粒度细化。比如对于一个社区系统来说，你可以先把和用户关系相关的业务逻辑，都拆分到用户关系服务中，之后，再把比如黑名单的逻辑独立成黑名单服务。

         原则三，拆分的过程，要尽量避免影响产品的日常功能迭代。

也就是说，要一边做产品功能迭代，一边完成服务化拆分。

还是拿我之前维护的一个项目举例。我曾经在竞品对手快速发展的时期做了服务的拆分，拆分的方式是停掉所有业务开发全盘推翻重构，结果错失了产品发展的最佳机会，最终败给了竞争对手。

 

因此，我们的拆分只能在现有一体化系统的基础上不断剥离业务独立部署，剥离的顺序你可以参考以下几点：

    1. 优先剥离比较独立的边界服务（比如短信服务、地理位置服务），从非核心的服务出发减少拆分对现有业务的影响，也给团队一个练习、试错的机会；

    2. 当两个服务存在依赖关系时优先拆分被依赖的服务。比如内容服务依赖于用户服务获取用户的基本信息，那么如果先把内容服务拆分出来，内容服务就会依赖于一体化架构中的用户模块，这样还是无法保证内容服务的快速部署能力。

    所以正确的做法是理清服务之间的调用关系，比如内容服务会依赖用户服务获取用户信息，互动服务会依赖内容服务，所以要按照先用户服务再内容服务，最后互动服务的顺序来进行拆分。

     原则四，服务接口的定义要具备可扩展性。

服务拆分之后，由于服务是以独立进程的方式部署，所以服务之间通信就不再是进程内部的方法调用而是跨进程的网络通信了。在这种通信模型下服务接口的定义要具备可扩展性，否则在服务变更时会造成意想不到的错误。

在之前的项目中，某一个微服务的接口有三个参数，在一次业务需求开发中，组内的一个同学将这个接口的参数调整为了四个，接口被调用的地方也做了修改，结果上线这个服务后却不断报错，无奈只能回滚。

这是因为这个接口先上线后参数变更成了四个，但是调用方还未变更还是在调用三个参数的接口，那就肯定会报错了。所以服务接口的参数类型最好是封装类，这样如果增加参数就不必变更接口的签名，而只需要在类中添加字段就可以了。