CoreOS的适应场景介绍

        CoreOS诞生之时，曾经介绍过自己是这样的一个系统：“面向大规模服务部署的操作系统（Linux for Massive Server Deployments）”。而且，它不仅支持的集群节点数足够庞大，还有其能够提供服务的快速大规模伸缩能力。

        对于CoreOS，至少有3个节点，否则Etcd的Leader节点选举将无法进行。集群节点的数量上限则受较多因素的影响，比如：节点间的物理距离、网络状况的好坏等等。

        一般来讲，分布式应用的数据同步和传输量会随着节点的增多而数量增加，即便是大规模集群架构，也只会有少量的几个保存有集群信息的核心节点，其他节点只是单纯的做为执行任务的工作节点而已。只要是3个节点及以上数目的节点便能够很好的利用CoreOS的自动升级、集群管理等特性来进行集群节点管理。

       但是，并不是所有的大规模集群应用都适合在CoreOS这样的系统上使用。主要有以下两个原因：第一，CoreOS的系统分区是只读的，因此，设计读写性较强且对宿主机进行定制或其他原因导致“无法容器化”的服务是不适合在CoreOS上运行的；第二，集群服务的可伸缩性并不是单纯的由操作系统本身就能保证的，对于有些无法将状态放置到服务外部（如：Nginx，MySql 安装在同一个容器镜像中的服务）,这种强耦合的服务即便通过容器运行在CoreOS集群上，也不能够有效地进行横向扩展，或者在系统故障时快速迁移到健康节点。

       判断集群是否适合使用CoreOS的一个关键依据是该应用服务是否能够容器化，且具有“面向无状态服务架构”的特点。面向无状态服务架构要求系统中的所有服务对单次请求的处理不依赖其他请求。也就是说，处理一次请求所需的全部信息要么都包含在请求里，要么可以从外部获取（如数据库、缓存），服务器本身不存储任何信息。典型的面向无状态服务架构的有RESTful服务架构、SOAP服务架构等。

        CoreOS的横向伸缩、故障迁移的本质都是通过在节点间启动更多的相同服务镜像实现的，但对于有状态的服务来说，镜像拷贝既不能使状态和数据的一致性得到保障，又不能使故障丢失掉的状态和数据在新的节点中恢复。那么对于集群里有状态的服务应该怎么办？一些基于状态机的无法，是可以通过修改业务逻辑将状态信息以类似Session的方式存放到外部的数据服务（数据库、缓存、分布式存储服务）中以在服务间共享，从而变为无状态服务。