共计 4433 个字符，预计需要花费 12 分钟才能阅读完成。
LAIN 是宜信公司大数据创新中心开发的开源 PaaS 平台。在金融的场景下，LAIN 是为解放各个团队和业务线的生产力而设计的一个云平台。LAIN 为宜信大数据创新中心各个团队提供了统一的测试和生产环境，简化了服务的部署与上线流程，也降低了运维人员对系统管理的复杂度。
一、设计理念及解决问题
LAIN 规范了一个应用的开发、测试、上线工作流，提供了为应用做的容器编排、权限控制、SDN、流量管理、监控报警、备份、日志等 devops 问题的整体解决方案。
在 LAIN 上，应用是一个基本的概念，某个应用的开发者只需要定义一个 lain.yaml 即可定义应用的编译和运行方式，对应用代码侵入性很低。LAIN 基于容器技术，面向多样化的技术栈，并且天然隔离系统和应用的依赖。
当 LAIN 用户创建一个应用（服务）时，可以到 LAIN 上注册该应用，当前的用户自动成为了该应用的维护者，拥有了进一步操作该应用的权限。构建应用的环境需要 docker 和 lain 命令行工具，为了方便，我们创建了一个 vagrant box 即 lain-box. 在构建应用时，除了工程代码外，还需要一个 Docker 镜像作为基础镜像，即编译的环境。如果是二进制的工程，如 golang，则可以在运行时换掉一个底，否则会使用 build 镜像为 release 镜像。准备好镜像和编译/运行的脚本后，就可以编辑 lain.yaml 了。
具体来说，LAIN 解决了以下四个问题：
1、应用开发之下的 devops 问题的整体解决方案
常见问题
- 面对用户的应用级开发仅仅是冰山一角，在此之下有机房、网络、服务器、系统管理、运维管理、监控、告警、日志等等一系列背后的工作，而这部份的工作可能比应用级开发还要复杂
- 采用 IaaS 解决了服务器采购和上架问题，但是依然需要一个强大的 devops 团队来负责上述事务，否则基础设施很容易成为发展瓶颈，且越拖越难解决
- 上面的这些工作对于每一个产品可能都是同质化但又伴随着定制，会消耗大量的时间做这些重复的工作
Lain 是怎么做的
- 直接在几乎裸的 IaaS 或者服务器上即可构建 lain 集群，方便地进行在线的扩容缩容等集群底层资源操作
- 整合了业界沉淀下来的良好的运维整体实践，提供了冰山下的这一大块工作的整体解决方案
- 将纷繁复杂的系统管理和运维管理行为封装为更简单易用的工具包，极大简化大部分的系统工作，降低日常维护的技术门槛和人力需求
- 将同质化的工作整合在一起，避免重复劳动
- 开箱即用的各种管理组件，囊括了部署，扩容，监控，告警，日志等方方面面。还有附赠应用，包括 mysql，redis 的集群服务
2、规范了应用开发的工作流程，并辅以适当的 SCM 支援
常见问题
- 在个人开发者以及 startup 组织中，良好的工作流这件事几乎是不会被提及的，然而在日渐发展的过程中遗留的技术债务却会越来越多的影响开发部署的效率和质量
- 设计、开发和部署行为的不规范会引发各种问题
Lain 是怎么做的
- 提供本地开发环境的解决方案
- 提供本地开发过程的 SDK / CLI 工具链，使得开发和构建过程是嵌入在解决方案中的
- 隐性的提供了 SCM 支援，约束了开发者的开发和发布行为
3、提高整体资源利用率，优化冗余资源池
常见问题
- 传统的按照产品线规划资源池的情况下，会给各产品预留专属的资源池以及配备冗余，以便进行灾备以及服务突发流量
- 然而各产品线的资源需求类型不同，冗余类型也不同，无法共通共享，造成众多的重复冗余，资源利用率比较低
- 通过服务器资源的冗余，扩容缩容，以及资源迁移的操作比较复杂，时间消耗大，风险高
Lain 是怎么做的
- 通过容器技术的资源隔离和控制，实现多种技术栈多种应用在集群内安全的不相互影响的混合部署，通过统一的资源池进行冗余，有效提高资源利用率
- 容器技术的运用使得对下资源的使用形成完全统一的形式，扩容缩容以及迁移的成本很低，操作也更简单。
4、TBD：架构上提供了服务治理的可能性和解决方案
二、特征
在应用的层面上，LAIN 还有以下特征：
1、基于配置文件定义应用
- 在现有的应用上只需要增加一个配置文件 lain.yaml 即可定义应用在 lain 集群里的编译和运行
- 对应用代码的侵入性很低
2、SDN 网络安全隔离
- 使用开源的 calico(https://github.com/projectcal…
- 高效率的应用内网络互通
- 应用间网络默认隔离
- 显式声明应用间的服务互访
3、基于容器技术支持多样化的技术栈
- 使用开源的 docker 项目构建容器云
- 扩展封装 Dockerfile，使用自定义的 yaml 格式进行应用的集群定义
- 只需符合最简单的 lain cluster runtime interface，可自由选择 base image
容器技术天然的支持隔离系统和应用的依赖
- lain SDK / CLI 以及可选的 ci 组件支援代码版本和镜像之间的对应关系
- 编译时和运行时镜像均可完全定制和隔离
4、应用在线扩容缩容
- 使用开源的 swarm 调度应用部署
深度封装 swarm docker API，自行开发集群控制器（deployd）以及应用控制器（console）
- 直接支持用户 API 调用进行容器实例数扩容，缩容
- 直接支持用户 API 调用进行容器单实例资源的扩容，缩容（CPU，MEM）
5、节点在线扩容缩容
- 使用开源的 ansible(https://github.com/ansible/an…
- 集群的服务器节点（NODE）兼容同一个 C 段内的物理服务器，虚拟机，公有云服务器
- 集群管理工具包支持 add NODE 和 remove NODE 指令，快速进行底层资源扩容和缩容
6、服务自动维持和灾难恢复
自行开发集群控制器（deployd）
- 容器实例级别的服务巡检和维持，自动迁移和服务恢复
- 基于虚 ip 自动漂移的入口 load balancer HA
- 高级 API 支持服务定制迁移
7、内部服务依赖和发现机制
集群支援 Service / Resource 机制
- 集群整体的服务应用
- 应用私有 Service（即 Resource）服务应用
- 集群支援特别的服务应用类型和资源应用类型
在 lain.yaml 中显式声明使用的 Service / Resource
- 基于 DNS 的服务发现机制
- 可编程的 service/resource load balancer
- 默认提供可用的 RoundRobin 类型的 load balancer
8、统一认证
- 集群自行开发统一认证组件（sso）
- 支持 oauth2 的多种认证方式
9、虚 ip 和负载均衡器统一管理
- 支援 virtual ip 和 应用 proc 的注册，应用可注册 virtual ip 来进行对外服务
- 基于 etcd lock 机制的 virtual ip 漂移机制，应用 load balancer 可借此实现 HA
10、web load balancer 的自动配置
- 使用开源的 nginx 和 tengine(https://github.com/alibaba/te…
自研的 watcher 检测集群应用的整体 runtime 数据，自动为 web 服务生成配置
- 获取 runtime 变化的时间，判断是否需要进行配置变更
- 配置变更事件出发配置的渲染
- 触发 reload 生效
11、集群体系化的日志收集
- 使用开源的 heka(https://github.com/mozilla-se…
- 默认收集应用的 stdout / stderr 日志收集
- 支援应用显式声明需要收集的落地文件日志
- 支援应用显式声明结构化的监控数据日志
- 定制检测 web 服务 load balancer 的 nginx 日志收集和数据统计
12、私有 docker registry 以及认证机制
- 使用开源的 docker registry 封装私有 registry 应用
- 集成支援集群的私有统一认证机制
- 定制支援可选的 moosefs 存储后端或者 Ceph 存储后端
13、应用配置加密存储
- 使用开源的库封装的应用私有配置加密存储组件
- 集成 sso 组件实现用户管理和权限隔离
- 在应用运行时阶段将配置注入
14、本地化开发环境
- 使用开源的 vagrant，免费的 centos 和 virtualbox 组织统一的本地化开发环境
- 甚至支援本地使用上述工具链 bootstrap 出一个 lain 本地集群
15、应用部署运维 API 以及相应的 CLI 客户端
- 应用的构建，发布，部署，运维都由集群的各组件提供 API
- 使用 lain SDK / CLI 再次封装上述 API，给用户提供良好的操作界面
- 集成集群的统一认证，进行用户管理和权限隔离
16、集群管理 CLI
- 使用开源的 ansible 开发集群管理运维工具包
- 再次封装 ansible 调用为简单的 CLI 使得操作更方便，包括增加节点，移除节点，迁移应用，集群健康检查等。
17、规范化的开发 workflow
- 基于上述组件，以代码 – 镜像的一一对应关系进行 SCM，对镜像进行发布管理
- 使用 lain SDK / CLI 以及可选的 ci 组件进行本地开发，构建发布，会很自然的规范开发 workflow
- 工作流运转的核心单位是镜像，lain cli 封装了镜像的生成，更新，推送，部署，运维
18、可选的集群体系化的备份和恢复（backupd + moosefs）
- 采用开源的 moosefs 作为分布式存储后端
- 支援在 lain.yaml 中显式声明 volume 备份需求和策略，以及设定备份策略的 hooks
- 支援指定备份恢复
19、可选的集群日志查询组件（kafka + elasticsearch + kibana）
- 采用开源的 kakfa，elasticsearch，kibana 搭建外部依赖的卡夫卡集群和 elasticsearch 集群，封装集群可选组件 libana
- rebellion 集群日志收集组件支援发送所有日志到上述外部依赖 kafka
- 在 libana 上支援对集群应用日志和 web load balancer 日志的条件组合查询
20、可选的系列预置应用
- MySQL 的服务 (https://github.com/laincloud/…
- MySQL 的资源
- Redis 的服务 -SM(https://github.com/laincloud/…
三、系统架构
1、物理视图
从物理层面看，每一个 lain 集群是由一个或多个网络互通的节点（Node）构成的。
每个节点可以被赋予不同的 label，供容器调度时进行节点选择使用。
目前的实现中，需要所有节点位于同一个路由器后。
2、逻辑视图
从逻辑层面看，一个 lain 集群是由多个应用组成，应用和应用之间网络相互隔离（通过 SDN 技术）。
每一个应用是由多个 Docker 容器组成，每个容器都可能运行在不同的节点上。
应用开发者可以在一个应用中定义多种容器（称为 proc），每个 proc 可以指定为在集群上运行多份，每份即为一个容器，被称为 proc instance。Lain 集群会尽可能保证有指定份数的容器在运行，如果有容器 crash 或者节点 fail 的情况发生，集群会试图重启容器或者在节点间迁移容器。
3、系统架构设计图
目标是做成一层一层可以深入的架构图
总图
节点
4、工作流程
GitHub 地址：https://github.com/laincloud
白皮书：https://laincloud.gitbooks.io…
来源：宜信技术学院
