# 深度学习平台术语

以下是开源深度学习平台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负责服务之间的管理（包括访问、限流、安全等）

# 5. 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来管的。