istio 1 - spring cloud微服务

spring cloud和istio

• service mesh被称下一代微服务概念，其中又以istio当前最火，目前总体覆盖率不高，大厂不差钱会试试水，但大多数中小公司还是停留在spring cloud或zk + dubbo阶段，新兴技术还是有必要学学，既然被称为下一代微服务，所以就以spring cloud开始写了。
• spring cloud开始时以Netflix的几个核心组件为主，但后来相继出现闭源、版本更替等问题，所以也都出现了各自组件的代替品，身边朋友公司用的比较多的就是原始Netflix版或Alibaba版，我所在的公司业务线使用的都是以Netflix为核心的spring cloud，下面简单总结相关组件Eureka、Ribbon、Feign、Hystrix、Zuul、Apollo、Sleuth。

注册中心Eureka

• 注册中心是微服务的核心功能，现在主流的注册中心有eureka、consul、zookeeper、nacos，注册中心主要的作用就是服务注册和发现，服务方注册到注册中心，使用方从注册中心获取被调用方ip进行通信，为避免单服务宕机风险一般都会以至少3节点的形式部署，多节点就必然会出现数据一致性的问题，为了保证一致性，就引出了CAP定理。
  • 一致性(Consistency) ：保证每个节点数据强一致
  • 可用性(Availability) ：在可容忍的超时范围内得到响应，无论成功失败
  • 分隔容忍(Partition tolerance) ：部分节点宕机不影响整体注册中心运作
• CAP定理原则是三者不可同时满足，最多3选2，一般都会在A和C中做选择，毕竟不想宕了一部分节点整体全瘫痪。
• CP：以zookeeper、consul为代表，需要实现一致性协议如paxos、raft，协议都会选出一个master，master接收消息并和各从节点通信保持数据一致，只要保证半数以上节点可用就可以维持正常，主节点宕机时从节点可以补位，但选举过程或半数以上节点宕机，会出现不可用的状况。
• AP：以eureka为代表，因为不需要强一致所以没有实现一致性协议，也称为peer to peer对等模式，实例注册到eureka一个节点就算成功，后续会广播到其他节点，所以也不需要和zookeeper、consul一样选举出master，但网络卡顿等问题各节点间数据会出现不一致。
• eureka相关概念：
  • 部署使用：eureka客户端嵌入在程序中，代码入侵性较强，好处在于部署上容易，如consul和要学的istio等都需要在服务本地单独启一个proxy服务单独用于调度，部署麻烦，各模块功能相对独立。
  • 自身注册：eureka服务端自身也可以当一个做实例注册到注册中心。
  • 实例缓存：客户端会保留实例缓存，不会每次都查询服务端，这样做也可以保证服务端宕机时临时可用。
  • 续约机制：客户端发送心跳间隔30s，服务端每10s检测一次剔除90s未发现心跳的实例，客户端即3次未续约就可能被剔除。
  • 自我保护：服务端15 分钟之内接收到的心跳低于 85%时会告警，并且触发不剔除实例，避免临时网络问题导致节点全部被剔除，达到自我保护的作用。

负载均衡Ribbon

• Ribbon是微服务里的负载均衡器，通常eureka配合使用，微服务的一个优势就是可以动态根据服务压力细粒度的扩展内部服务数量，eureka上一般被调用方是一组服务集群，所以就需要用到负载算法，Ribbon只做负载，所以需要配合调用方式才能使用，例如后续的feign，也可以直接搭配RestTemplate使用。
• 负载算法：RandomRule随机、RoundRobinRule线性轮询、RetryRule线性轮询+重试、WeightedResponseTimeRule根据响应时间分配等等。
• ribbon原理上就是从eureka中根据服务名拿取备选IP根据负载算法选定IP，拦截RestTemplate然后把URL里的服务名字换成IP发起真正的请求。

API调用Feign

• eureka + Rabbion + http，Feign默认使用Rabbion，所以负载策略也是一样的，写法上稍有不同，增加了自定义编解码、压缩、日志记录等功能。

断路器Hystrix

• 跨服务调用会出现调用异常情况，如网络延时，会导致请求拥堵，大量请求拥堵或异常到一定阈值时就需要触发熔断，并且熔断后一段时间内的不再发出请求，避免整个服务器瘫痪，一段时间后如果请求正常就恢复请求，并且也需要可视化看到异常原因并解决异常，Hystrix常会和feign一起使用。
• Hystrix：
  1. 包裹请求：命令模式，命令在独立线程中执行。
  2. 跳闸机制：超过错误率阈值自动或手动跳闸。
  3. 资源隔离：每个依赖维护一个线程池或信号量，如果线程池已满就拒绝避免 资源耗尽。
  4. 监控：hystrix提供可视化监控请求成功失败情况，也可以使用mq一消息形式接收监控数据。
  5. 回退机制：熔断后的处理，可自定义服务降级的回调方法。
  6. 自我修复：一段时间后如果请求正常就恢复请求。
• 隔离策略：线程池（默认），信号量（负载高、非网络调用场景）

微服务网关Zuul

• zuul可以用来执行权限校验、根据业务动态路由、监控流量、负载等等，网关也可以组成集群，一般请求不会直接发送到zuul上，前端会经过LVS + NGINX或硬件F5的负载分发到zuul集群，至此请求就算进入微服务体系里了，zuul也可以使用hytrix ribbon的功能。
• 路由基本流程：
  • 接收请求，取出对象参数
  • 根据配置，构造并发起发起新请求
  • 获取新请求响应，返回客户端

注册中心Apollo

• 后续会单独出个Apollo部分，连带源码分析

链路监控Sleuth

• sleuth微服务的链路监控，很多情况下微服务调用链路关系复杂、链路长，需要一个链路监控工具，sleuth使用时有两个id，spanID和traceID，traceID是整个调用链的ID，spanID是每个跨度也就是调用链表示每个过程的ID，以日志的形式展示出来。
• sleuth还可以和ELK一起使用，ELK是常见的日志收集工具，分别代表Elasticsearch、Logstash和Kibana，使用时日志压力比较大，所以一般会和filebeat、kafka一起使用，常间的cat、zipkin和skywalking也可以做链路监控，cat属于埋点式收集数据，代码入侵性高，其他两种暂时没用过。
• ELK常用组件：
  • filebeat安装在需要收集日志的服务器上，负责把增长的日志发到kafka
  • kafka收集各个服务的日志到队列中避免压力过大
  • Logstash负责过滤转发，可以在Logstash配置规则，把日志拆分成字段，放入ES以供展示
  • Elasticsearch负责存储格式化后的日志数据
  • Kibana提供可视化展示

• istio本身以k8s为基础，不太熟练，正在恶补中，// todo 详细看完k8s再回来继续..