01.单体和微服务介绍

1.1 单体服务架构

1.2 微服务架构介绍

通俗来说，微服务架构就是把一个大系统按业务功能分解成多个职责单一的小系统，并利用简单的方法使多个小系统相互协作，组合成一个大系统

• 微服务（Microservices）是一种架构风格，一个大型复杂软件应用由一个或多个微服务组成。
• 系统中的各个微服务可被独立部署，各个微服务之间是松耦合的。
• 每个微服务仅关注于完成一件任务并很好地完成该任务。
• 在所有情况下，每个任务代表着一个小的业务能力。

1.3 简单微服务访问缺陷

• 比如要查询订单商品信息
  • 第一：通过 用户 服务的ip和端口号访问到用户信息
  • 第二：拿着用户返回的信息，去查询 订单 服务ip和端口号查询到订单
  • 第三： 拿着订单的信息，去查询 产品 服务 ip:端口号 查询到最终商品的信息
• 缺点：
  • 一旦某一个服务升级后，ip和端口号发生变化，所有调用服务都需要修改调用的ip和端口和重启服务

1.4 域名解决方案

• 微服务访问之域名解析
  • 这个时候每一个服务都需要一个nginx代理，到后面的真实服务集群中
  • 这样会使得整个服务变得很复杂

02.微服务架构

2.1 微服务组件

• 服务注册：Eureka、consul、nacos
  • 服务提供方将自己调用地址注册到服务注册中心，让服务调用方能够方便地找到自己。
• 服务发现：Config、consul、nacos
  • 服务调用方从服务注册中心找到自己需要调用的服务的地址。
• 负载均衡：Ribbon
  • 服务提供方一般以多实例的形式提供服务，负载均衡功能能够让服务调用方连接到合适的服务节点。
  • 并且，节点选择的工作对服务调用方来说是透明的。
• 服务网关：ZUUL
  • 服务网关是服务调用的唯一入口，可以在这个组件是实现用户鉴权、动态路由、灰度发布、A/B 测试、负载限流等功能。
• 配置中心：Config
  • 将本地化的配置信息（properties, xml, yaml 等）注册到配置中心，实现程序包在开发、测试、生产环境的无差别性，方便程序包的迁移。
• API 管理：
  • 以方便的形式编写及更新 API 文档，并以方便的形式供调用者查看和测试。
• 集成框架：Spring-cloud、Double、Go-micro
  • 微服务组件都以职责单一的程序包对外提供服务，
  • 集成框架以配置的形式将所有微服务组件（特别是管理端组件）集成到统一的界面框架下
  • 让用户能够在统一的界面中使用系统。
• 分布式事务：
  • 对于重要的业务，需要通过分布式事务技术（TCC、高可用消息服务、最大努力通知）保证数据的一致性。
• 调用链：Skywalking
  • 记录完成一个业务逻辑时调用到的微服务，并将这种串行或并行的调用关系展示出来。
  • 在系统出错时，可以方便地找到出错点。
• 支撑平台：
  • 系统微服务化后，系统变得更加碎片化，系统的部署、运维、监控等都比单体架构更加复杂，那么，就需要将大部分的工作自动化。
  • 现在，可以通过 Docker 等工具来中和这些微服务架构带来的弊端。
  • 例如持续集成、蓝绿发布、健康检查、性能健康等等。
  • 可以这么说，如果没有合适的支撑平台或工具，就不要使用微服务架构。

2.2 微服务架构优点

• 降低系统复杂度：每个服务都比较简单，只关注于一个业务功能。
• 松耦合：微服务架构方式是松耦合的，每个微服务可由不同团队独立开发，互不影响。
• 跨语言：
  • 只要符合服务 API 契约，开发人员可以自由选择开发技术。
  • 这就意味着开发人员可以采用新技术编写或重构服务，由于服务相对较小，所以这并不会对整体应用造成太大影响。
• 独立部署：
  • 微服务架构可以使每个微服务独立部署，开发人员无需协调对服务升级或更改的部署。
  • 这些更改可以在测试通过后立即部署，所以微服务架构也使得 CI／CD 成为可能。
• Docker 容器：和 Docker 容器结合的更好。
• DDD 领域驱动设计：和 DDD 的概念契合，结合开发会更好。

2.3 微服务架构的缺点

• 微服务的分布式特点带来的复杂性：
  • 开发人员需要基于 RPC 或者消息实现微服务之间的调用和通信
  • 而这就使得服务之间的发现、服务调用链的跟踪和质量问题变得的相当棘手
• 分区的数据库体系和分布式事务：
  • 更新多个业务实体的业务交易相当普遍，不同服务可能拥有不同的数据库。
  • CAP 原理的约束，使得我们不得不放弃传统的强一致性，而转而追求最终一致性，这个对开发人员来说是一个挑战。
• 测试挑战：
  • 传统的单体WEB应用只需测试单一的 REST API 即可，而对微服务进行测试，需要启动它依赖的所有其他服务。
  • 这种复杂性不可低估。
• 跨多个服务的更改：
  • 比如在传统单体应用中，若有 A、B、C 三个服务需要更改，A 依赖 B，B 依赖 C。
  • 我们只需更改相应的模块，然后一次性部署即可。
  • 但是在微服务架构中，我们需要仔细规划和协调每个服务的变更部署。
  • 我们需要先更新 C，然后更新 B，最后更新 A。
• 部署复杂：
  • 微服务由不同的大量服务构成，每种服务可能拥有自己的配置、应用实例数量以及基础服务地址。
  • 这里就需要不同的配置、部署、扩展和监控组件。
  • 此外，我们还需要服务发现机制，以便服务可以发现与其通信的其他服务的地址。
  • 因此，成功部署微服务应用需要开发人员有更好地部署策略和高度自动化的水平。
• 总的来说（问题和挑战）：
  • API Gateway、服务间调用、服务发现、服务容错、服务部署、数据调用。

03.微服务实现流程

3.1 微服务实现流程

1、服务都注册到服务注册中心

• 要构建微服务体系，首先我们需要独立部署一款实现服务注册/发现功能的组件服务，目前可供选择的主流方案一般有Eureka、Consul、Nacos等
• 搞定服务注册/发现后，我们编写一个Java微服务，此时为了将该服务注册到服务注册中心
• 一般会引入Spring Cloud提供的支持对应注册中心接入的SDK，并在应用入口类中通过@EnableDiscoveryClient注解的方式标注
• 之后SDK中的逻辑就会在应用启动时执行服务注册动作，并提供给注册中心相应地探测接口，以此实现微服务与服务注册中心之间的连接。
• 以此类推，我们可以通过这种方式将一组微服务都注册到服务注册中心！

2、服务之间要互相调用

• 一般我们会通过编写FeignClient接口来实现微服务之间的调用
• 而其底层的逻辑则是通过Feign所集成的Ribbon组件去注册中心中获取目标服务的服务地址列表
• 之后Ribbon根据服务地址列表进行负载均衡调用。
• 至于服务与注册中心之间如何保证连接有效性，则依赖于服务注册中心与其SDK之间的协作机制。

3、负载均衡、熔断、限流、网关

• 而高级一点，服务之间的调用除了实现负载均衡，还要实现熔断限流
• 那么此时可以通过部署服务网关组件（例如Zuul/Spring Cloud GateWay）来实现微服务入口的熔断限流
• 内部服务之间的限流熔断则通过集成Hystrix或Sentinel组件，以客户端本地配置或远程配置中心的方式来实现。

3.2 微服务遇到的问题

1、框架/SDK太多，后续升级维护困难

• 在这套体系中，与服务治理相关的逻辑都是以SDK代码依赖的方式嵌入在微服务之中
• 如果某天我们想升级下服务注册中心的SDK版本，或者熔断限流组件Hystrix或Sentinel的版本，那么需要升级改造的微服务可能会是成百上千
• 且由于这些组件都与业务应用绑定在一起，在升级的过程中会不会影响业务稳定，这都是需要谨慎对待的事情，所以对SDK的升级难度可想而知的！

2、多语言微服务SDK维护成本高

• 试想下如果构建的微服务体系，也要支持像Go、Python或者其他语言编写的微服务的话
• 那么上述这些微服务治理相关的SDK是不是得单独再维护几套呢？
• 所以在这种体系结构中，对多语言微服务的支持就成了一个问题！

3、服务治理策略难以统一控制

• 基于该套体系构建的微服务体系，在对像熔断、限流、负载均衡等服务治理相关的策略管理上，都是比较分散的
• 可能有人会写到自己的本地配置文件，有人会硬编码到代码逻辑中，也可能有人会将其配置到远程配置中心
• 总之对于服务治理策略逻辑都是由对应的开发人员自己控制，这样就很难形成统一的控制体系！

4、服务治理逻辑嵌入业务应用，占有业务服务资源

• 在这套微服务体系中，服务治理相关的逻辑都是在微服务应用进程中寄生运行的
• 这多少会占有宝贵的业务服务器资源，影响应用性能的发挥！

5、额外的服务治理组件的维护成本

• 无论是服务注册中心、还是服务网关，这些除了微服务应用本身之外服务治理组件，都需要我们以中间件基础服务的方式进行维护
• 需要额外的人力、额外的服务器成本

04.各语言微服务框架

4.1 Java

Spring Boot

• Spring Boot的设计目的是简化新Spring应用初始搭建以及开发过程，2017年有64.4%的受访者决定使用Spring Boot，可以说是最受欢迎的微服务开发框架。
• 利用Spring Boot开发的便捷度简化分布式系统基础设施的开发，比如像配置中心、注册、负载均衡等方面都可以做到一键启动和一键部署。

Spring Cloud

• Spring Cloud是一个系列框架的合计，基于HTTP（s）的RETS服务构建服务体系，Spring Cloud能够帮助架构师构建一整套完整的微服务架构技术生态链。

Dubbo

• Dubbo是由阿里巴巴开源的分布式服务化治理框架，通过RPC请求方式访问。
• Dubbo是在阿里巴巴的电商平台中逐渐探索演进所形成的，经历过复杂业务的高并发挑战，比Spring Cloud的开源时间还要早。
• 目前阿里、京东、当当、携程、去哪等一些企业都在使用Dubbo。

Dropwizard

• Dropwizard将Java生态系统中各个问题域里最好的组建集成于一身，能够快速打造一个Rest风格的后台，还可以整合Dropwizard核心以外的项目。
• 国内现在使用Dropwizard还很少，资源也不多，但是与Spring Boot相比，Dropwizard在轻量化上更有优势，同时如果用过Spring，那么基本也会使用Spring Boot。

框架对比

• 从公司整体规划： 不会选择很久没人维护的 dubbo，重启之后也未必是原班人马

• 从程序员招聘难度 ：招 springcloud 的程序员会更好招，因为更新更炫

• 从系统结构简易程序：

  • springcloud 的系统结构更简单、“注册 + springmvc=springcloud”
  • 而 dubbo 各种复杂的 Url，protocol，register，invocation，dubbofilter，dubboSPI，dubbo 序列化.......... 炫技的成分更多一些

• 从性能：

  • dubbo 的网络消耗小于 springcloud，但是在国内 95% 的公司内，网络消耗不是什么太大问题
  • 如果真的成了问题，通过压缩、二进制、高速缓存、分段降级等方法，很容易解

• 从开发难易度：

  • dubbo 的神坑是 jar 包依赖，开发阶段难度极大

4.2 Go

• Go-Kit是分布式开发的工具合集，适合用于大型业务场景下构建微服务；
• Goa是用Go语言构建的微服务框架；
• Dubbogo是和阿里巴巴开源的Dubbo能够兼容的Golang微服务框架。

4.3 Python

• Python相关的微服务框架非常少，用的比较多的是Nameko。
• Nameko让实现微服务变得更简单，同时也提供了很丰富的功能，比如支持负载均衡、服务发现还支持依赖自动注入等
• 使用起来很方便，但是有限速、超时和权限机制不完善等缺点。