第二课主要是《K8s权威指南》中的基本概念与术语以及调度 9.29组会上提到的一些概念

微服务提取

从单体应用 中提取出对应的微服务

数据血缘

数据血缘，即对各资源涉及的数据流经路径进⾏跟踪，类似于追踪数据的「⾎缘关系」。 其可针对数据向下做影响分析或向上做溯源分析，有助于⽤户管理资源和排查问题。具体为：

  • 影响分析：了解资源（如数据源 / 数据表 / API / 数据模型 / SQL 模型等）被下游的使⽤情况，便于在更改资源时评估影响。
  • 溯源分析：对资源（如图表 / 数据模型）的错误 / 疑问进⾏溯源，查明根因。 第三课

服务容器化

第一步 第二步 应用无状态 Session的管理方式，客户端或者服务端 第三步 微服务 单体应用拆分为微服务。轻量化与可复用，

服务发现

why？

Pod的IP不固定，（Docker默认是动态IP，可以设置固定ip） 需要一个负载均衡服务器，管理对Pod副本的访问 外部路由，集群外访问pod

基于以上原因，实现了Service的概念 没有selector的服务用来将service转发到集群外， NodePort，每个集群的Node开一个端口监听并转发服务，内部可以直接使用NodeIP加NodePort访问。在集群外部有一个负载均衡器，向这些端口转发数据，负载均衡深度结合云平台，由云平台提供， Service自己实现了软负载均衡，负责控制转发向不同的Pod的流量，以及从虚拟的集群IP映射到NodeIp的功能。至于DNS是从Service域名解析到集群IP，只要将Service声明为负载均衡器， KubeDNS和CoreDNS Ingress 路由规则，将流量转发到服务，

调度

深度掌握Pod-玩转Pod podAffinity pod亲和性，要不要把Pod放在同一组Node上， PodAntiAffinity反亲和

云平台的两个问题

一个是储存，CSI的发展还在开发中， 一个 是网络，虚拟机的网络怎么分析， 集群太大的一个问题是master节点的负载，主流解决方案是少发数据，

应用场景

架构演变

单体应用架构 集群服务架构，SOA服务架构，微服务架构 50%以上的重复企业代码 有过一个故事，有一批人尝试不进行开发，只重用代码，结果失败。 微服务特点一个微服务一个数据库，虽然不强制但是，微服务推荐分库，否则，多个微服务可能在数据库访问层面上出现竞争

康威定律

组织架构等于 软件架构

软件架构大多数时候都会降低效率，之所以引入架构是为了方便开发与运维管理

中台的概念越来越大，逐渐吞并了前端后端，前端只剩下页面，后端只剩下数据库

CAP理论 ，三缺一 RWN 假设三个分区，每次写数据，写两个分区，读数据，读两个分区，对比一些得到最新数据 实现弱一致性，也就是最终一致性，BASE