k8s构建 k8s + Istio 微服务

•  实验环境：
  k8s 集群： k8s 的控制节点
  ip：192.168.1.30
  主机名：k8s-master1
  配置：4vCPU/4Gi 内存
  k8s 的工作节点：
  ip：192.168.1.40
  主机名：k8s-01
  配置：4vCPU/8Gi 内存

• Istio 称的上是最新一代微服务，目前社区活跃度极高，跟 k8s 有很好的互补，那什么是微服务呢？

• 微服务可以从两个方面理解：
  
  微：小的意思，大家可以搜索下 2 pizza（两个披萨原则），这个 2 pizza 原则最早是亚马逊 CEO 贝索斯提出来的，他认为如果两个披萨不足以喂饱一个项目团队，那么这个团队可能就显得太大了，因为人数过多的项目会议将不利于决策的形成，而让一个小团队在一起做项目、开会讨论，则更有利于达成共识，并能有效促进企业内部创新。
  
  服务：相对较小且独立的功能单元
  
  官方解释：
  微服务是用于构建应用程序的架构风格，一个大的系统可由一个或者多个服务组成，微服务架构可将应用拆分成多个核心功能，每个功能都被称为一项服务，可以单独构建和部署，这意味着各项服务在工作和出现故障的时候不会相互影响。简单来说，微服务架构是把一个大的系统按照不同的业务单元分解成多个职责单一的小系统，并利用简单的方法使多个小系统相互协作，组合成一个大系统，各个小的系统是独立部署的，它们之间是松耦合。

  

  

• 微服务架构的优势
  1、可以让产品更快的上市
  由于开发周期缩短，微服务架构有助于实现更加敏捷的部署和更新。
  2、高度可扩展
  随着某些服务的不断扩展，你可以跨多个服务器和基础架构进行部署，充分满足自身需求。
  3、出色的弹性
  只要确保正确构建，这些独立的服务就不会彼此影响。这意味着，一个服务出现故障不会导致整个应用下线。
  4、易于部署
  相对于传统的单体式应用，基于微服务的应用更加模块化且小巧，所以无需为它们的部署操心。
  5、易于访问
  由于大型应用被拆分成了多个小型服务，所以开发人员能够更加轻松地理解、更新和增强这些服务，从而缩短开发周期。
  6、更加开放
  由于使用了多语言 API，所以开发人员可以根据需要实现的功能，自由选用最适合的语言和技术。

• 微服务架构发展进程
  第一代微服务框架
  SpringCloud
  springCloud 为开发者提供了快速构建分布式系统的通用模型的工具，主要是针对 java 的开发框架
  第二代微服务框架
  dubbo
  Dubbo 是一个阿里巴巴开源出来的一个分布式服务框架，致力于提供高性能和透明化的 RPC 远程
  服务调用方案，以及 SOA 服务治理方案
  第三代微服务框架
  1.Service Mesh（服务网格）
  istio 是开源的 Service Mesh（服务网格），Service Mesh 翻译成中文就是服务网格

• 微服务框架对比分析
  主流微服务框架：SpringCloud、Dubbo
  新锐微服务框架：k8s+istio

• 框架背景对比
  （1）Spring Cloud，来源于 SpringSource ，具有 Spring 社区的强大背景支持，还有 Netflix
  强大的后盾与技术输出。
  
  扩展：Netflix 是什么？
  Netflix 作为一家成功实践微服务架构的互联网公司，在几年前就把几乎整个微服务框架开源贡献给
  了社区，这些框架开源的整套微服务架构套件是 SpringCloud 的核心。包括：
  Eureka: 服务注册发现框架；
  Zuul: 服务网关；
  Karyon: 服务端框架；
  Ribbon: 客户端框架；
  Hystrix: 服务容错组件；
  Archaius: 服务配置组件；
  Servo: Metrics 组件；
  Blitz4j: 日志组件。
  
  （2）Dubbo 是一个分布式服务框架，是国内互联网公司阿里开放的微服务化治理框架，致力于提
  供高性能和透明化的 RPC 远程过程调用方案，以及 SOA 服务治理方案。 其核心部分包含）: 
  集群容错: 提供基于接口方法的透明远程过程调用，包括多协议支持，以及软负载均衡，失败容错，
  地址路由，动态配置等集群支持；
  
  自动发现: 基于注册中心目录服务，使服务消费方能动态的查找服务提供方，使地址透明，使服务提
  供方可以平滑增加或减少机器。
  简单的理解是一个节点请求另一个节点提供的服务
  
  扩展：SOA（面向服务的架构）
  面向服务的架构（SOA）是一个组件模型，它将应用程序的不同功能单元（称为服务）进行拆分，
  并通过这些服务之间定义良好的接口和协议联系起来。接口是采用中立的方式进行定义的，它应该独立于实现服务的硬件平台、操作系统和编程语言。这使得构建在各种各样的系统中的服务可以以一种统一和通用的方式进行交互。
  
  （3）Istio 作为用于微服务服务聚合层管理的新锐项目，是 Google、IBM、Lyft（海外共享出行
  公司、Uber 劲敌） 首个共同联合开源的项目，提供了统一的连接，安全，管理和监控微服务的方案。

• 开源社区活跃度对比
  开源社区情况：现如今企业在采用云计算首选开源，而选择一个开源框架，社区的活跃度将作为重要
  参考选项。
  
  查看下在 Github 上的更新时间
  Spring Cloud ：Spring Cloud · GitHub → 所有项目均更新于『1 小时』内。
  Dubbo ：Dubbo · GitHub → 核心项目最近更新于『一个月乃至数月』前。
  istio：istio · GitHub → 所有项目均更新于『30 分钟』内。
  
  总结：结合项目背景、提供功能、社区更新活跃度，SpringCloud 是目前阶段发展最早的微服务框
  架方案，Istio 作为 Kubernetes 的优先支持来讲，也是一个值得关注的方案，而且发展潜力巨大，相
  信不久的将来 90%+的 k8s 用户都会使用 istio。

• 使用微服务需要解决的问题

• 配置中心
  微服务为什么要解决配置中心问题？
  在企业中，一般都有 2-4 种环境：开发，测试，交付，生产这四种，这几种环境的配置也有所变化，我们在部署的时候通常不能一个配置文件部署四个环境，这些环境的配置是不通用的。这就要用到k8s 原生的配置中心 configMap 就是用解决这个问题的
  
  常见的配置中心有哪些：Nacos、Apollo、SpringCloud Config、k8s configmap
• 配置管理流程：
  配置的权限管理、灰度发布、版本管理、格式检验和安全配置等一系列的配置管理相关的特性也是配置中心不可获取的一部分。
  1）权限管理
  配置的变更和代码变更都是对应用运行逻辑的改变，重要的配置变更常常会带来核弹的效果， 通过项目的维度来对配置进行权限管理，一个项目的 owner 可以授权给其他用户配置的修改发布权限。
  2）灰度发布
  配置的灰度发布是配置中心比较重要的功能，当配置的变更影响比较大的时候，需要先在部分应用实例中验证配置的变更是否符合预期，然后再推送到所有应用实例。
  3）版本管理&回滚
  当配置变更不符合预期的时候，需要根据配置的发布版本进行回滚。
  4）配置格式校验
  应用的配置数据存储在配置中心一般都会以一种配置格式存储，比如 Properties、Json、Yaml学等，如果配置格式错误，会导致客户端解析配置失败引起生产故障，配置中心对配置的格式校验能够有效防止人为错误操作的发生，是配置中心核心功能中的刚需。

• 服务发现

  

• 假设我们写的代码要调用 REST API 服务，代码需要知道服务实例的网络位置（IP 地址和端口）。运行在物理硬件上的传统应用中，服务实例的网络位置是相对固定的。如果服务部署到 k8s 或者容器中，服务地址是由集群系统动态分配的。这时我们需要访问这个服务时，如何确定它的地址呢？这时就需要服务发现（Service Discovery）了。
• 以 k8s 中部署应用为例：
  Pod 是由生命周期的，如果 Pod 重启 IP 会发生变化。
  如果我们的服务都是将 Pod 的 IP 地址写死，Pod 的挂掉或者重启，后端其他服务也将会不可用，那我们只能通过手动修改如 nginx 的 upstream 配置来改变后端的服务 IP。在我们可以通过，Consul，ZooKeeper 还有我们熟悉的 etcd 等工具，有了这些工具过后我们就可以只需要把我们的服务注册到这些服务发现中心去就可以。
• Kubernetes 集群就为我们提供了这样的一个对象 - Service，Service 是一种抽象的对象，它定义了一组 Pod 的逻辑集合和一个用于访问它们的策略，其实这个概念和微服务非常类似。一个 Serivce 下面包含的 Pod 一般是由 Label Selector 来决定的。
  我们这样就可以不用去管后端的 Pod 如何变化，只需要指定 Service 的地址就可以了，因为我们在中间添加了一层服务发现的中间件，Pod 销毁或者重启后，把这个 Pod 的地址注册到这个服务发现中心去。Service 的这种抽象就可以帮我们达到这种解耦的目的。 

•  Istio 概念、架构、组件详细介绍

• Istio 是什么？
• Istio 是一个与 Kubernetes 紧密结合的适用于云原生场景下用于服务治理的开放平台。
   
• 服务治理包括：
  连接（Connect）、安全（Secure）、策略执行（Control）和可观察性（Observe）。
  官网：https://istio.io
  
  
  1）连接：
  Istio 通过集中配置的流量规则控制服务间的流量和调用，实现负载均衡、熔断、故障注入、重试、重定向等服务治理功能。
  2）安全：
  Istio 提供透明的认证机制、通道加密、服务访问授权等安全能力，可增强服务访问的安全性。
  3）策略执行：
  Istio 通过可动态插拔、可扩展的策略实现访问控制、速率限制、配额管理、服务计费等能力。
  4）可观察性：
  动态获取服务运行数据和输出，提供强大的调用链、监控和调用日志收集输出的能力。配合可视化工具，可方便运维人员了解服务的运行状态，发现并解决问题。
  5）策略与遥测：
  常常需要为服务设置一定的授权策略，比如限制流量的速率、设置黑名单等。另外，遥测（Telemetry）也是一个很重要的功能，可以通过分析收集到的指标（Metric）来监控系统的状态。在Istio 中，策略设定和遥测都是通过 Mixer 组件完成的（mixer 在 1.5+已经被废弃了，整合到 istiod 中了）

• Istio 核心特性
  1）、流控(traffic management)
  断路器(circuit breakers)、超时、重试、多路由规则、AB 测试、灰度发布、按照百分比分配流量等。
  2）、安全(security)
  加密、身份认证、服务到服务的权限控制、K8S 里容器到容器的权限控制等。
  3）、可观察(observability)
  追踪、监控、数据收集，通过控制后台全面了解上行下行流量，服务链路情况，服务运行情况，系统性能情况，国内微服务架构体系，这一块做得比较缺乏。
  4）、平台无关系(platform support)
  K8s，物理机，自己的虚机都没问题。
  5）、集成与定制(integration and customization)
  可定制化扩展功能。

• 断路器：
  举个生活中的例子解释断路器
  当电路发生故障或异常时，伴随着电流不断升高，并且升高的电流有可能能损坏电路中的某些重要器件，也有可能烧毁电路甚至造成火灾。若电路中正确地安置了保险丝，那么保险丝就会在电流异常升高到一定的高度和热度的时候，自身熔断切断电流，从而起到保护电路安全运行的作用。很多技术都是来源生活的，随着社会进步，科技发展
  
  断路器也称为服务熔断，在多个服务调用的时候，服务 A 依赖服务 B，服务 B 依赖服务 C，如果服务 C 响应时间过长或者不可用，则会让服务 B 占用太多系统资源，而服务 A 也依赖服 B，同时也在占用大量的系统资源，造成系统雪崩的情况出现。 Istio 断路器通过网格中的边车对流量进行拦截判断处理，避免了在代码中侵入控制逻辑，非常方便的就实服务熔断的能力。

  

• 服务降级（提高用户体验效果）
  比如电商平台，在针对 618、双 11 的时候会有一些秒杀场景，秒杀的时候请求量大，可能会返回报错标志“当前请求人数多，请稍后重试”等，如果使用服务降级，无法提供服务的时候，消费者会调用降级的操作，返回服务不可用等信息，或者返回提前准备好的静态页面写好的信息。
• 超时
  什么时候需要用到超时？
  在生产环境中经常会碰到由于调用方等待下游的响应过长，堆积大量的请求阻塞了自身服务，造成雪
  崩的情况，通过超时处理来避免由于无限期等待造成的故障，进而增强服务的可用性。
  通过例子来理解：

  

• 重试
  istio 重试机制就是如果调用服务失败，Envoy 代理尝试连接服务的最大次数。而默认情况下，
  Envoy 代理在失败后并不会尝试重新连接服务。
  举个例子：

  

• 多路由规则
  1）、HTTP 重定向（HTTPRedirect）
  2）、HTTP 重写（HTTPRewrite）
  3）、HTTP 重试（HTTPRetry）
  4）、HTTP 故障注入（HTTPFaultInjection）
  5）、HTTP 跨域资源共享（CorsPolicy） 

• Istio 架构

  

  istio 服务网格从逻辑上分为数据平面和控制平面。
  1、数据平面由部署为 Sidecar 的一组智能代理(Envoy+Polit-agent)组成。这些代理承载并控制微服务之间的所有网络通信，管理入口和出口流量，类似于一线员工。
  2、控制平面管理并配置代理来进行流量路由。
  3、istio1.5+中使用了一个全新的部署模式，重建了控制平面，将原有的多个组件整合为一个单体结构 istiod，这个组件是控制平面的核心，负责处理配置、证书分发、sidecar 注入等各种功能。i