长春网站建设q479185700強,wordpress数学公式的代码,济南网站建设的费用,网站怎么做来流量吗转载自 从 Spring Cloud 看一个微服务框架的「五脏六腑」
Spring Cloud 是一个基于 Spring Boot 实现的微服务框架#xff0c;它包含了实现微服务架构所需的各种组件。 注#xff1a;Spring Boot 简单理解就是简化 Spring 项目的搭建、配置、组合的框架。因为与构建微服务本…转载自 从 Spring Cloud 看一个微服务框架的「五脏六腑」
Spring Cloud 是一个基于 Spring Boot 实现的微服务框架它包含了实现微服务架构所需的各种组件。 注Spring Boot 简单理解就是简化 Spring 项目的搭建、配置、组合的框架。因为与构建微服务本身没有直接关系所以本文不对 Spring Boot 进行展开。另外本文有一些例子涉及到 Spring 和 Spring Boot建议先了解一下 Spring 和 Spring Boot 再阅读本文。 本文的阅读对象主要是没有接触过服务架构想对其有一个宏观的了解的同学。 本文将从 Spring Cloud 出发分两小节讲述微服务框架的「五脏六腑」
第一小节「服务架构」旨在说明的包括两点一服务架构是什么及其必要性二是服务架构的基本组成。为什么第一节写服务架构而不是微服务架构呢原因主要是微服务架构本身与服务架构有着千丝万缕的关系服务架构是微服务架构的根基。第二小节「五脏六腑」则将结合 Spring Cloud 这个特例来介绍一个完整的微服务框架的组成。
「服务架构」
为了方便理解我先讲一个小故事改编自一知乎答主
Martin微服务提出者也叫 Martin刚来到公司时是一个基层员工它上面有经理、老板那个时候所有人都听老板的指挥。
但是过了两年公司的人越来越多原来的模式下整个公司的运作效率太低管理也很混乱。
于是已经踏上中层岗位的 Martin 建议老板进行部门划分服务化专门的部门只做专门的事情单一职责。例如研发部门只做研发人事部门只做招聘。
老板听取了 Martin 的意见对公司的组织架构进行了调整。
有一天Martin 发现公司的部门越来越多各个部门并不能完全知道对方所做的事情这对跨部门协作服务调用带来了困难。
行政部门会注册中心来记录所有的部门每当有新的部门行政都会记录下来服务注册然后公布出来让所有部门知道服务发现。
在新的组织架构下公司的效率逐步提高。老板也给 Martin 发了大量奖金作为奖励Martin 从此赢取白富美走向了人生巅峰。
这是一个公司组织架构演变的故事主要讲的是随着公司规模的扩大组织从集中化管理到分布化管理的过程。
映射到我们的信息系统里来也是一样的随着我们的系统越来越复杂变得难以管理也有人想到去拆分然后治理。在解决复杂问题上分治可以说是一个屡试不爽的办法。
服务化即是拆解的一种手段。而上面圆括号里面的内容其实就对应了一个服务化架构的最小组成元素分别是服务、服务调用、注册中心、服务注册、服务发现。有了这些基本的组成要素就可以实现一个最简单的服务架构。
面向服务的架构和微服务架构
面向服务的架构SOA和微服务架构是目前两种主流的服务化架构都符合上面的例子也有上面提到的所有组件。这两种服务架构有很多可以讲的但是与本文的相关性不大本文不做会过多展开只简单介绍一下两者的区别。
准确地说微服务是去 ESB企业服务总线的 SOA。ESB 借鉴了计算机组成原理中的通信模型 —— 总线所有需要和外部系统通信的系统通过 ESB 进行标准化地转换从而消除协议、异构系统之间的差异这样就可以利用现有的系统构建一个全新的松耦合的异构的分布式系统。微服务架构去掉 ESB本质上是一种去中心化的思想。
「五脏六腑」
「心脏」
顺着上一节的思路从最简单、最核心的问题出发假设服务 A 要调用服务 B会有什么问题
服务在哪服务治理问题怎么调用服务调用问题
这两个是最核心的问题也是任何微服务框架首要解决的两个问题。
为了解决第一个问题 Spring Cloud 提供了 Eureka、Zookeeper、Cloud Foundry、Consul 等服务治理框架的集成。它们的工作模式是将所有的微服务注册到一个 Server 上然后通过心跳进行服务健康监测。这样服务 A 调用 B 时可以从注册中心拿到可用的服务 B 的地址、端口进行调用。
第二个服务调用有人可能认为就是一个简单的 HTTP 或者 RPC 调用不是什么问题。但是在分布式的场景下服务调用需要考虑的因素会更多。比如一个服务有多个实例此时请求进来了交给谁处理请求的负载怎么平衡到各个实例都是比较棘手的问题。Spring Cloud 提供了两种服务调用的方式一种是 Ribbon restTemplate另一种是 Feign。
其中 Ribbon 是基于 HTTP 和 TCP 客户端的负载均衡器restTemplate 是 Spring 提供的 Restful 远程调用的模板两者结合就可以达到远程调用的负载均衡。
而 Feign 是一个更加声明式的 HTTP 客户端开发者可以像调用本地方法一样调用它完全感觉不到是远程调用结合 Ribbon 也可以做负载均衡。
既然两个问题都得到了解决我们就用一个例子来进一步说明一下例子包含了微服务中最基本的三个角色注册中心、服务提供者、服务消费者)
注册中心
注解 EnableEurekaServer 表示该 Spring Boot 应用是一个注册中心。
EnableEurekaServer
SpringBootApplication
public class EurekaserverApplication {public static void main(String[] args) {SpringApplication.run(EurekaserverApplication.class, args);}
}eureka.client.registerWithEureka: false 和fetchRegistry: false 来表明自己是一个 eureka server。
server:port: 8080eureka:instance:hostname: localhostclient:registerWithEureka: falsefetchRegistry: falseserviceUrl:defaultZone: http://${eureka.instance.hostname}:${server.port}/eureka/service-hello 服务
注解 EnableEurekaClient 表示他是一个 Eureka 客户端它会在注册中心注册自己。
注解 RestController 表示这是一个控制器RequestMapping(/hello) 表示匹配到请求 /hello 时会调用该方法进行响应。
SpringBootApplication
EnableEurekaClient
RestController
public class ServiceHelloApplication {public static void main(String[] args) {SpringApplication.run(ServiceHelloApplication.class, args);}Value(${server.port})String port;RequestMapping(/hello)public String home(RequestParam String name) {return hello name,i am from port: port;}}注册中心的地址为 http://localhost:8080/eureka/也就是上面我们定义的。服务名为 service-hello将会被调用者使用。
eureka:client:serviceUrl:defaultZone: http://localhost:8080/eureka/
server:port: 8081
spring:application:name: service-hello服务消费者 service-ribbon
假设 service-ribbon 端口为 8082当我们访问 http://localhost:8080/hello 时HelloControler 接收到请求并调用 HelloService 中的 helloService 方法HelloService 中通过定义的 restTemplate 去调用 http://service-hello/hello。此处要注意的是 LoadBalanced 注解它表示启用负载均衡。
SpringBootApplication
EnableDiscoveryClient
public class ServiceRibbonApplication {public static void main(String[] args) {SpringApplication.run(ServiceRibbonApplication.class, args);}BeanLoadBalancedRestTemplate restTemplate() {return new RestTemplate();}}Service
public class HelloService {AutowiredRestTemplate restTemplate;public String helloService(String name) {return restTemplate.getForObject(http://service-hello/hello?namename,String.class);}}RestController
public class HelloControler {AutowiredHelloService helloService;RequestMapping(value /hello)public String hello(RequestParam String name){return helloService.helloService(name);}}至此其实一个微服务应用的雏形已经搭建出来了服务治理、服务调用可以说是「五脏六腑」中的「心脏」。
「心脏」的依托
接下来我们要进一步思考的是「五脏六腑」中其余的部分因为少了它们人也是活不久的。下面通过一个问题或需求对应一个组件的方式进行介绍。
服务“雪崩”与断路器
由于网络等原因服务并不能保证 100% 可用如果单个服务出现问题调用这个服务就会出现线程阻塞此时若有大量的请求涌入Servlet 容器的线程资源会被消耗殆尽导致服务瘫痪。
由于服务与服务之间存在依赖故障会在调用链路上传播导致整个微服务系统崩溃这就是服务故障的“雪崩”效应。
为了解决这个问题Spring Cloud 提供了对 Hystrix 断路器的集成当服务调用失败的频次达到一定阈值断路器将被开启降级的策略可以开发者制定一般是返回一个固定值。这样就能够避免连锁故障。
此外 Spring Cloud 还提供 Hystrix Dashboard 和 Hystrix Turbine帮助我们进行监控和聚合监控。
服务暴露与路由网关
微服务中的服务很多直接暴露给用户一是不安全二是对用户不友好。因此在微服务和面向服务的架构中通常会有一个路由网关的角色来负责路由转发和过滤。对应到 Spring Cloud 中有 Zuul 和 Gateway 两个组件可用。
路由网关接收了所有的用户请求有着很高的负载因此它通常是一个集群。用户的请求会先经过一层负载均衡被发到路由网关。
服务配置与配置中心
在微服务应用中服务数量巨多而每个服务不同环境都有着不同的配置为了方便服务配置文件统一管理实时更新所以需要分布式配置中心组件。需要注意的是此处的配置与注册中心注册的配置信息是两个概念此处的配置是服务本身的一些配置信息如下图 Spring Cloud 提供了 Spring Cloud Config 组件它支持配置服务放在配置服务的内存中即本地也支持放在远程 Git 仓库中帮助我们管理服务的配置信息。
信息同步与消息总线
前一个问题讲到了每个服务都有一些配置信息那么配置信息更新了我们该怎么办手动一个个去更新当然不是Spring Cloud 提供了 Spring Cloud Bus 组件它通过轻量消息代理连接各个分布的节点。当配置信息更新的时候我们只要更新一个节点的配置这个更新就会被广播到这个分布式系统中。
问题定位与链路追踪
在微服务系统中服务之间可以相互调用因此我们一个请求可能会一条调用链而整个系统会存在一张调用网其中任意一个服务调用失败或网络超时都可能导致整个请求失败。因为调用关系的复杂这给问题的定位造成了极大的困难这也是必须提供服务链路追踪的原因。
Spring Cloud 为我们提供了 Spring Cloud Sleuth 组件它能够跟进一个请求到底有哪些服务参与参与的顺序是怎样的从而达到每个请求的步骤清晰可见。借助服务链路追踪我们可以快速定位问题。
至此Spring Cloud 的所有基础组件都介绍完了。但是目前所有的组件介绍都是分散的它们组合起来完整的样子是什么样的如下图 偷懒偷了张图图中漏掉了 Config Server 和链路追踪组件。但是结合上文的介绍我们大致可以脑补出这两个东西在图中的位置。Config Server 是一个与所有服务相连的服务集群链路追踪组件则集成在每个服务中。 小结
服务治理为心脏路由网关、消息中心、断路器、链路追踪、配置中心等为依托构造了整个微服务框架的「五脏六腑」。当然一个微服务系统远比本文所写的复杂得多尤其是在不同的业务场景之下因此想要更深入地了解它就需要我们不断地去实践。而作为前端我了解这些内容一是为了更好地了解整个请求的流程二是为了后续在 SOA 中接入 Node 子服务积累相关知识。
最后分享一句有趣的调侃 Spring 的话在 Spring 中没有什么是一个注解解决不了的如果有那么就用两个注解。
