以下是开源深度学习平台kubeflow需要了解的相关术语。掌握它们，会更加理解搭建一个深度学习平台所需要的概念或框架。
1. RPC
提供远程调用对方的函数的框架。
远程过程调用带来的新问题：
- Call ID映射。
- 序列化和反序列化。
- 网络传输
https://www.zhihu.com/question/25536695
2. gRPC
google出的RPC框架，基于http2。可对外提供grpc服务。
3. 微服务
微服务有两个核心：
- 微：服务的粒度要细，即服务要细化到API
- 服务：提供好服务，要让用户感到好用(要做到这一点很不容易)
微服务特别简单（好的架构就应该简单），我们把服务再拆分成一个个API，API是一个完整的功能。然后我们把API扔到一个“云上”，然后用户就可以到“云上”获取所有API的服务，这个“云”保证能提供好的服务。
微服务的关键是服务网关，所以，上面提到的“云”就是服务网关。服务网关之下，就是内部系统之间的服务治理，这就是另外一个话题了。
实现方案:https://blog.csdn.net/suifeng3051/article/details/53992560
Docker 和Kubernetes 技术的流行, 为Pass资源的分配管理和服务的部署提供了新的解决方案, 但是微服务领域的其他服务治理问题仍然存在.
4. 服务治理
服务化（常利用RPC框架实现）。但服务化还有挑战：
- 服务越来越多，配置管理复杂
- 服务间依赖关系复杂
- 服务之间的负载均衡
- 服务的拓展
- 服务监控
- 服务降级
- 服务鉴权
- 服务上线与下线
所以服务治理是关键（dubbo就是一个带有服务治理功能的RPC框架）。服务治理理应具有：
- 服务注册, 服务发现
- 服务伸缩
- 健康检查
- 快速部署
- 服务容错: 断路器, 限流, 隔离舱, 熔断保护, 服务降级等等
- 认证和授权
- 灰度发布方案
- 服务调用可观测性, 指标收集
- 配置管理
简单理解，大量的内部服务之间需要一个机制，去互相发现、流量管控等业务之外的问题，这个机制就是服务治理。Istio就是服务治理的框架实践（Service Mesh概念属于服务治理概念内，都在Istio中有实现）。
5. Istio
简单理解，k8s负责把服务部署起来，Istio负责服务之间的管理（包括访问、限流、安全等）
6. GPU
GPU是显卡的处理器，称为图形处理器（Graphics Processing Unit，即GPU），又称显示核心、视觉处理器、显示芯片，是一种专门在个人电脑、工作站、游戏机和一些移动设备（如平板电脑、智能手机等）上图像运算工作的微处理器，它是显卡的“心脏”，与CPU类似，只不过GPU是专为执行复杂的数学和几何计算而设计的，这些计算是图形渲染所必需的。
CPU是“主（host）”而GPU是“从（device）”，GPU无论发展得多快，都只能是替CPU分担工作，而不是取代CPU。GPU是显卡上的一块芯片，就像CPU是主板上的一块芯片。
GUP与CPU
CPU和GPU之所以大不相同，是由于其设计目标的不同，它们分别针对了两种不同的应用场景。CPU负责逻辑性强的事物处理和串行计算，GPU则专注于执行高度线程化的并行处理任务（大规模计算任务）。
CPU需要很强的通用性来处理各种不同的数据类型，同时逻辑判断又会引入大量的分支跳转和中断的处理，这些都使得CPU的内部结构异常复杂。
GPU面对的则是类型高度统一的、相互无依赖的大规模数据和不需要被打断的纯净的计算环境。
CPU擅长逻辑控制，串行的运算。和通用类型数据运算不同，GPU擅长的是大规模并发计算，这也正是密码破解等所需要的。所以GPU除了图像处理，也越来越多的参与到计算当中来。
总而言之，CPU和GPU因为最初用来处理的任务就不同，所以设计上有不小的区别。而某些任务和GPU最初用来解决的问题比较相似，所以用GPU来算了。GPU的工作大部分就是这样，计算量大，但没什么技术含量，而且要重复很多很多次。GPU的运算速度取决于雇了多少小学生，CPU的运算速度取决于请了多么厉害的教授。教授处理复杂任务的能力是碾压小学生的，但是对于没那么复杂，但是量特别大的任务，还是顶不住人多。当然现在的GPU也能做一些稍微复杂的工作了，相当于升级成初中生高中生的水平。但还需要CPU来把数据喂到嘴边才能开始干活，究竟还是靠CPU来管的。
标签：术语,服务,平台,Istio,API,治理,深度,GPU,CPU From： https://www.cnblogs.com/wpshan/p/18546766