分布式架构手记

August 25, 2016

这几天尝试了很多的 *aaS, 期望能找到在当前架构下适合公司后续发展的一个系统架构, 然而一路下来发现并没那么简单.

由于人员紧缺,规模扩展,越来越多的基础设施需要管理部署和控制,并且公司没有自己的设施,主要的基础设施来源于 阿里云, 这也不知道是福还是祸.

Kubernetes 用于容器集群进行管理,让用户忽略底层的 IaaS, 但如果没有底层的 IaaS 那么 Kubernetes 用起来是举步维艰的.我们想要实现的是 SaaS, 需要的平台是 PaaS Kubernetes, 那么需要的基础设施 IaaS 用于运行 Kubernetes 的平台必须要与 Kubernetes 十分"友好"才能让你感觉 Kubernetes 是一个有价值的系统.而阿里云并不在"友好"之列. Kubernetes 原生支持 Azure, GCE, AWS, 如果公司选择的是这其中一家平台的服务,那么我相信 Kubernetes 还是很好用的,那用阿里+ Kubernetes 的不便在何处?

  • 阿里云并算不上一个合格的 IaaS, 只是服务器租赁商
  • Kubernetes 无法对阿里云服务器做任何控制
  • 阿里云现有服务无法和 Kubernetes 整合

这就使得本来很简单的东西变得很麻烦了,因为发现很多东西都得自己做.我的目标是想要使用基于 Kubernetes 的 Deis, Kubernetes 缺少与底层 IaaS 的集成使得 Deis 几乎无法使用(例如: IP 的分配).诚然 Kubernetes 很好,然而与我们无缘.

因为所有的主机都是 Ubuntu 的,想要尝试 juju, 遇到与上述完全相同的问题,无法与云平台集成.而 MAAS, 感觉上不太成熟,使用起来不太友好所以选择了放弃.到头来似乎简单轻量的 Docker Swarm 是唯一的选择.

运行平台选定了,可是状态存储也是一大问题. Docker Volume 集成的第三方云存储基本是用不上的(例如: EFS,Azure File Storage),涉及到存储的例如 Docker Registry, 代码仓库,但阿里的 OSS 似乎在这里也是指望不上的,剩下的唯一选择也就只能自己搭建了.Ceph 似乎是不二选择, 只要能接受在阿里上购买足够多的硬盘即可.

使用 Docker Swarm 用于部署服务层是很方便的,但是对于代码仓库或 Docker Registry 还是建议部署于单台服务器中.使用 Overlay 进行网络隔离以实现不同的环境部署服务.

Tags:架构