网易伏羲云原生游戏中间件平台实践
环境依赖：服务可能会因为基础环境的变化导致异常情况。
缺少标准化：各个游戏项目对中间件的使用方式存在差异。
缺少平台统一动态管理：缺少统一平台进行创建、删除等自主运维能力。
服务可靠性低：服务不可用等状态难以及时发现，以及人工修复效率比较低。
灵活性：各个游戏业务对基础服务使用存在差异，需要满足各个业务多样化的需求。
稳定性：云环境中存在节点异常、网络IO抖动，磁盘IO抖动等各种情况，这些情况都有可能导致服务异常，基础服务直接影响上层业务的稳定性和项目的推进，因此如何保证服务的稳定性十分重要。
故障自愈：由于各种异常情况，服务可能存在主动退出、或者被动退出的情况。当出现服务的情况，服务需要具备自愈能力，服务能够被快速重新拉起，并且保证服务中数据的不丢失，从而避免人工介入修复。
易观测：中间件运行的过程中，运行日志，指标参数需要能被完善收集便捷的展示，帮助用户了解中间件服务运行的状态。
中间件生命周期管理：中间件服务的生命周期管理就是对中间件的各个状态进行管理，各个状态具有对应可执行的操作。
实时标准输出、标准错误输出日志，业务服务层日志查询服务通过调用Kubernetes API获取中间件容器的实时标准输出、标准错误输出日志，然后展示到用户层。
日志存储及检索，Kubernetes中容器重启等场景会使得日志丢失，因此需要将中间件容器的标准输出、标准错误输出日志持久化的进行存储，并且支持日志检索等需求。架构如下：
节点监控，节点的指标收集通过node exporter实现。node exporter通过DaemonSet方式部署在Kubernetes的每个节点上，用于采集节点的运行指标，包括节点CPU，内存，文件系统等指标。
Kubernetes资源状态监控，kube-state-metrics采用Deployment方式部署，通过监听Kubernetes apiserver将Kubernetes资源的数据生成相应指标。在云原生游戏中间件平台场景下，我们需要对自定义游戏中间件资源状态进行监控。
容器监控，cAdvisor对节点容器进行实时监控和性能数据采集，包括CPU使用情况、内存使用情况、网络吞吐量及文件系统使用情况。cAdvisor以及集成在kubelet中，当kubelet启动时会自动启动cAdvisor。
游戏中间件服务监控，上述监控从Kubernetes资源状态、节点、容器层进行，而更细粒度的就需要游戏中间件服务本身进行监控，不同游戏中间件需要监控的服务指标也不相同。游戏中间件平台层就需要针对各个中间件资源实现各自的exporter，从而达到服务级别的监控。
type Cacheserver struct {
metav1.TypeMeta `json:",inline"`
metav1.ObjectMeta `json:"metadata,omitempty"`
Spec CacheserverSpec `json:"spec,omitempty"`
Status CacheserverStatus `json:"status,omitempty"`
}
type CacheserverSpec struct {
Storage int64 `json:"storage"`
Image string `json:"image"`
Resources corev1.ResourceRequirements `json:"resources"`
Cleaner Cleaner `json:"cleaner"`
Tolerations []corev1.Toleration `json:"tolerations"`
NodeSelector map[string]string `json:"nodeSelector"`
ImagePullSecrets []corev1.LocalObjectReference `json:"imagePullSecrets,omitempty"`
}
type CacheserverStatus struct {
Phase string `json:"phase"`
}
type Cleaner struct {
Webhook string `json:"webhook"`
Image string `json:"image"`
}
基础信息：名称、Namepace、CacheServer镜像、Cleaner镜像、镜像拉取Secret等。
资源配置：CPU、内存、持久化存储大小。
调度：CacheServer Pod调度配置Tolerance、NodeSelector等。
资源管理：管理CacheServer所包含的Pod、Service等子资源。Operator通过list、watch监听CacheServer事件（创建、更新、删除），发送到Resource Handler的队列中，由控制循环取出事件并处理。创建资源时将子资源的OwnerReference设置成父资源，可以在删除CacheServer时利用kubernetes级联删除有效删除子资源。
状态管理：实时更新CacheServer的运行状态。Operator通过list、watch循环监听CacheServer Pod资源，根据Pod运行状态，更新CacheServer的状态。
hostPath：映射宿主机文件系统中的文件或者目录到Pod，需要数据清理等管理。local volume需要维护挂载点。本方案采用emptyDir的方式。
emptyDir：Pod分配到Node上时被创建，Kubernetes会在Node上自动分配一个目录，因此无需指定宿主机Node上对应的目录文件。
local volume：通过PVC方式访问宿主机的本地存储，但静态provisioner仅支持发现和管理挂载点，必须将它们通过bind-mounted的方式绑定到发现目录中。
affinity:
podAntiAffinity:
preferredDuringSchedulingIgnoredDuringExecution:
- podAffinityTerm:
labelSelector:
matchLabels:
app.kubernetes.io/managed-by: cacheserver-operator
topologyKey: kubernetes.io/hostname
weight: 100
内核参数优化：包括net.ipv4.tcp_sack，net.core.rmem_max，net.core.wmem_max，net.core.wmem_default，net.ipv4.tcp_mem，net.ipv4.tcp_rmem，net.ipv4.tcp_wmem等。
硬件升级：磁盘使用SSD，提升ardb数据的读写能力。
支持更多的游戏中间件上云，为游戏提供更全面支持。
游戏中间件Operator引擎：将游戏中间件特点进行抽象，Yaml定义的方式实现游戏中间件Operator通用特性，帮助快速实现游戏中间件Operator。
游戏中间件调度：增加调度的维度，帮助中间件更合理的进行调度。提升资源利用率，和高性能等。