2020-05-20—微服务中的名词
SOA
面向服务架构，它可以根据需求通过网络对松散耦合的粗粒度应用组件进行分布式部署、组合和使用。服务层是SOA的基础，可以直接被应用调用，从而有效控制系统中与软件代理交互的人为依赖性。
SOA是一种粗粒度、松耦合服务架构，服务之间通过简单、精确定义接口进行通讯，不涉及底层编程接口和通讯模型。SOA可以看作是B/S模型、XML（标准通用标记语言的子集）/Web Service技术之后的自然延伸。
SOA将能够帮助软件工程师们站在一个新的高度理解企业级架构中的各种组件的开发、部署形式，它将帮助企业系统架构者以更迅速、更可靠、更具重用性架构整个业务系统。较之以往，以SOA架构的系统能够更加从容地面对业务的急剧变化。
SOA系统是一种企业通用性架构。
一．系统吞度量要素：
一个系统的吞度量（承压能力）与request对CPU的消耗、外部接口、IO等等紧密关联。
单个reqeust 对CPU消耗越高，外部系统接口、IO影响速度越慢，系统吞吐能力越低，反之越高。
系统吞吐量几个重要参数：QPS（TPS）、并发数、响应时间
QPS（TPS）：每秒钟request/事务 数量
并发数： 系统同时处理的request/事务数
响应时间： 一般取平均响应时间
（很多人经常会把并发数和TPS理解混淆）
理解了上面三个要素的意义之后，就能推算出它们之间的关系：
QPS（TPS）= 并发数/平均响应时间
一个系统吞吐量通常由QPS（TPS）、并发数两个因素决定，每套系统这两个值都有一个相对极限值，在应用场景访问压力下，只要某一项达到系统最高值，系统的吞吐量就上不去了，如果压力继续增大，系统的吞吐量反而会下降，原因是系统超负荷工作，上下文切换、内存等等其它消耗导致系统性能下降。
决定系统响应时间要素
我们做项目要排计划，可以多人同时并发做多项任务，也可以一个人或者多个人串行工作，始终会有一条关键路径，这条路径就是项目的工期。
系统一次调用的响应时间跟项目计划一样，也有一条关键路径，这个关键路径是就是系统影响时间；
关键路径是有CPU运算、IO、外部系统响应等等组成。
QPS和TPS的区别
QPS（TPS）= 并发数/平均响应时间
QPS：
Queries Per Second 意思是“每秒查询率”，是一台服务器每秒能够相应的查询次数，是对一个特定的查询服务器在规定时间内所处理流量多少的衡量标准。
TPS：
Transactions Per Second 的缩写，也就是事务数/秒。它是软件测试结果的测量单位。一个事务是指一个客户机向服务器发送请求然后服务器做出反应的过程。客户机在发送请时开始计时，收到服务器响应后结束计时，以此来计算使用的时间和完成的事务个数。
PV、UV、IV
1、pv访问量（Page View），即页面访问量，每打开一次页面PV计数+1，刷新页面也是。
2、UV访问数（Unique Visitor）指独立访客访问数，一台电脑终端为一个访客。
3、IV是初始向量（IV，Initialization Vector）。
PV简介：
PV（page view）即页面浏览量，通常是衡量一个网络新闻频道或网站甚至一条网络新闻的主要指标。网页浏览数是评价网站流量最常用的指标之一，简称为PV。监测网站PV的变化趋势和分析其变化原因是很多站长定期要做的工作。 Page Views中的Page一般是指普通的html网页，也包含php、jsp等动态产生的html内容。来自浏览器的一次html内容请求会被看作一个PV，逐渐累计成为PV总数。
除了PV总数外，还可以从不同角度来分析和对比PV，比如想知道哪个网页(Page)被浏览的次数多就要以Page为分析对象并分别累计PV。网页一般通过URL或标题(html title)来标识，大多数工具都提供了类似的定义方法]关于PV的统计要考虑2种特殊情况：
一是从服务器返回错误网页或重定向网页时，是否计数以及如何配置；二是本地或网关服务器的缓存生效时是否计数。这些问题在实施网站分析前需要搞清楚，必要时可以咨询工具厂商。
UV简介：
UV是指不同的、通过互联网访问、浏览这个网页的自然人。
比如，在一台电脑上，哥哥打开了微软的官方主页，注册了一个会员。弟弟一会儿也看了看，注册了另一个会员。由于兄弟两个使用的是相同的计算机，那么他们的 ip是一样的，微软的官方计数器记录到一个ip登陆的信息。
但是，具有统计功能的统计系统，可以根据其他条件判断出实际使用的用户数量，返回给网站建设者真实、可信和准确的信息。比如通过注册的用户，甚至可以区分出网吧、机房等共享一个ip地址的不同计算机。
IV简介：
在有线等效保密（WEP）协议中，IV是用来和密钥组合成密钥种子，作为RC4算法的输入，来产生加密字节流对数据进行加密的。标准的64比特WEP使用40比特的钥匙接上24比特的初向量(Initialization Vector，IV) 成为 RC4 用的钥匙。
SpringCloud微服务配置过程中的名词
Eureka Server
依赖于：spring-cloud-starter-eureka-server （默认是服务端和客户端为一体的）
作为服务使用时，一般需要关闭掉客户端的功能
注册中心，可以注册服务的提供者，服务的调用者，服务网关，服务跟踪者，配置服务等
当需要多个注册中心时，可以配置和其他注册中心同步，实现高可用
Eureka Client
依赖于：spring-cloud-starter-eureka-server
任何需要注册到注册中心的服务，都是Eureka Clinet，可以是服务提供者，调用者，服务网关，服务跟踪者，配置服务等
Ribbon
- 客户端的负载均衡器
- ribbon是一个负载均衡客户端，可以很好的控制http和tcp的一些行为
- 依赖于：spring-cloud-starter-eureka-server，spring-cloud-starter-ribbon
- 结合restTemplate使用，通过@ LoadBalanced注册表明，这个restTemplate是负载均衡的
- 支持简单的URL访问，复杂的不太适合
- 可以单独使用，不依赖于Eureka
Eureka|Ribbon架构图：
Hystrix
断路器，防止微服务出现雪崩现象
依赖于：spring-cloud-starter-hystrix
有的SpringCloud版本默认已经为Feign整合了Hystrix（亲自测试Edgware是没有自动支持的，需要添加依赖并在配置文件中开启），我们要做的是自定义添加回退函数和原因
Feign
它是一个声明式的http客户端负载功能，其实也是依赖Ribbon
使用的时候坑还是有点多的，要多注意
通过注解方式，弥补了Ribbon访问时只适合URL的方式
依赖于：spring-cloud-starter-eureka-server，spring-cloud-starter-feign(包含了Ribbon，Hystrix)
Feign有自己的注解，但是spring为了降低大家的使用成本，对其做了一些封装改造，很多的地方可以使用spring的注解来操作
使用注解@FeignClient(value = “服务名”)来指定哪个服务
Zuul
网关中心，外部客户端统一调用网关，由网关协调各服务调用
依赖于：spring-cloud-starter-zuul
网关中心好处：易于监控，易于认证，减少客户端与各个微服务之间的交互次数
Eureka|Ribbon|Feign|Zuul 架构图：
SpringCloudConfig
分布式配置中心，分为服务端server和客户端client
依赖于：spring-cloud-config-server,spring-cloud-starter-eureka-server
config-client从config-server获取了foo的属性
config-server从git仓库中获取配置，仓库可以是本地也可以是远程
http请求地址和资源文件映射如下:
/{application}/{profile}[/{label}]
/{application}-{profile}.yml
/{label}/{application}-{profile}.yml
/{application}-{profile}.properties
/{label}/{application}-{profile}.properties
Spring Cloud Bus
- 消息总线
Sleuth
- 追踪器，为spring cloud 提供了分布式跟踪的解决方案
- 依赖于： spring-cloud-starter-sleuth
- 一般还会同其他的日志系统结合使用：ELK
SpringCloud整体图
服务续约
EurekaClient在注册到EurekaServer端之后，会通过启动时初始化的定时任务定时向EurekaServer端进行服务续约(心跳)，不断的向EurekaServer发送心跳。
服务保活
如果从前一次发送心跳开始，有90秒还没有接收到新的心跳，将剔除服务
服务续约 发送心跳时间间隔，每隔30S,发送一次心跳 |
服务雪崩
雪崩的过程:
分析：雪崩是系统中的蝴蝶效应导致其发生的原因多种多样，有不合理的容量设计，或者是高并发 下某一个方法响应变慢，亦或是某台机器的资源耗尽。从源头上我们无法完全杜绝雪崩源头 的发生，但是雪崩的根本原因来源于服务之间的强依赖，所以我们可以提前评估。当整个微 服务系统中，有一个节点出现异常情况，就有可能在高并发的情况下出现雪崩，导致调用它 的上游系统出现响应延迟，响应延迟就会导致 tomcat 连接本耗尽，导致该服务节点不能正 常的接收到正常的情况，这就是服务雪崩行为。
上面是一组简单的服务依赖关系A，B服务同时依赖于基础服务C，基础服务C又调用了服务D。
服务D是一个辅助类型服务，整个业务不依赖于D服务，某天D服务突然响应时间变长，导致了核心服务C响应时间变长，其上请求越积越多，C服务也出现了响应变慢的情况，由于A，B强依赖于服务C，故而一个无关紧要的服务却影响了整个系统的可用。
雪崩是系统中的蝴蝶效应导致其发生的原因多种多样，有不合理的容量设计，或者是高并发下某一个方法响应变慢，亦或是某台机器的资源耗尽。从源头上我们无法完全杜绝雪崩源头的发生，但是雪崩的根本原因来源于服务之间的强依赖，所以我们可以提前评估，做好熔断，隔离，限流。
参照简书博客：https://www.jianshu.com/p/acfb4ac2b124
服务隔离
如果整个系统雪崩是由于一个接口导致的，由于这一个接口响应不及时导致问题，那么我们 就有必要对这个接口进行隔离，就是只允许这个接口最多能接受多少的并发，做了这样的限 制后，该接口的主机就会空余线程出来接收其他的情况，不会被哪个坏了的接口占用满。 Hystrix 就是一个不错的服务隔离框架。
服务容错
容错技术是一个大的概念，广义上说，就是系统对错误的容忍能力。以服务器为例，当服务器出现故障的时候，如何确保系统不中断。需要注意的是，导致系统中断的因素有很多，不仅仅是服务器的故障，软件错误，或者外界突发因素都可以导致系统故障。系统故障有两种情况，一个是系统瘫痪了，业务中断。这种故障容易察觉，此外，还有另外一种故障，就是受外界影响，服务器的计算结果产生错误，这种情况下，系统不会瘫痪，但会产生错误的计算结果，这种故障不容易察觉，但危害也更加巨大。即所谓可信计算的问题。
服务降级
概念：服务降级，当服务器压力剧增的情况下，根据当前业务情况及流量对一些服务和页面有策略的降级，以此释放服务器资源以保证核心任务的正常运行。
服务接口拒绝服务：页面能访问，但是添加删除提示服务器繁忙。页面内容也可在Varnish或CDN内获取。
页面拒绝服务：页面提示由于服务繁忙此服务暂停。跳转到varnish或nginx的一个静态页面。
延迟持久化：页面访问照常，但是涉及记录变更，会提示稍晚能看到结果，将数据记录到异步队列或log，服务恢复后执行。
随机拒绝服务：服务接口随机拒绝服务，让用户重试，目前较少有人采用。因为用户体验不佳。
服务熔断
如果某个目标服务调用慢或者有大量超时，此时，熔断该服务的调用，对于后续调用请求，不在继续调用目标服务，直接返回，快速释放资源。如果目标服务情况好转则恢复调用。
熔断设计
三个模块：熔断请求判断算法、熔断恢复机制、熔断报警
（1）熔断请求判断机制算法：使用无锁循环队列计数，每个熔断器默认维护10个bucket，每1秒一个bucket，每个blucket记录请求的成功、失败、超时、拒绝的状态，默认错误超过50%且10秒内超过20个请求进行中断拦截。
（2）熔断恢复：对于被熔断的请求，每隔5s允许部分请求通过，若请求都是健康的（RT<250ms）则对请求健康恢复。
（3）熔断报警：对于熔断的请求打日志，异常请求超过某些设定则报警
服务限流
限流模式主要是提前对各个类型的请求设置最高的QPS阈值，若高于设置的阈值则对该请求直接返回，不再调用后续资源。
2020-05-20—微服务中的名词
