在网上看到了一款号称云时代的操作系统：数人云，简单看了一下其产品Demo：https://dashboard.shurenyun.com/cluster/listclusters ，瞬间觉得很眼熟，有种似曾相识的感觉，原来和我2012~2013年时候，在EISOO平台研发部门时候，为当时的云存储后端系统设计的那个管理后台初版有点像。不过那时候还涉及到集群管理，节点管理等等，比这个更复杂一些，那个是供IT管理员使用的后台系统；
我2011年时候接触到Openstack，转眼之间，已经是时隔四年多了。那时候的IaaS有OpenStack、CloudStack、Eucalyptus和OpenNebula，当然AWS另说。我当时经历过Openstack的D~G版本的迭代，不过目前Openstack已经是L版本了，当时很有兴趣继续深入研究OpenStack，但可惜，公司的决策层战略方向与定位决定了，最终主要做传统的私有云存储系统，当时对于像UCloud、七牛、UpCloud、青云等等互联网式的云服务并无太多兴趣；EISOO注定了是一个相对传统和保守的公司，不过稳扎稳打也是其优势；与个人而言，对于感兴趣的东西，在当时的工作机会过程中，未曾深入研究，有点遗憾。
扯远了，回来，其实经历过云计算，也不算遗憾。我从08年接触到云计算的概念，就认为他在未来将会很有用处，事实也确实如此，云计算的应用场景将越来越广泛。
云不仅仅整合了物理资源、使得计算、存储、网络等资源得到虚拟化和更高效的使用，也节省了资源，当然这是IaaS。
而现在PaaS、SaaS也大行其道，当平台、软件等等都逐渐以服务化的方式提供出来的时候，这其实也是整个科技发展的一次大的重构。
云时代，服务化、少耦合，架构演进，毫无疑问，将在未来创造非常多的精彩，极大的改善人们的生活，创业环境，让一切变得简化，高效。
架构与测试的重要性
记得以前刚毕业的时候，参加过CMMI3过程改进事宜，接触过 RUP，统一软件过程的理念。RUP的理念对我的架构有很深的影响，RUP其实是再讲下面这三个特点：
- 用例和风险驱动Use Case and risk driven
- 架构中心Architecture centric
- 迭代和增量Iterative and incremental
RUP很注重架构，提倡以架构和风险驱动，该开始一定要做端到端的原型prototype；通过压测验证架构可行性，然后在原型基础上持续迭代和增量式开发，开发->测试->调整架构->开发，循环，如下图所示：
架构师做好框架之后，开发人员写代码，测试人员需要尽快对架构进行验证。纸上谈兵式做架构而后丢给团队的作法非常不靠谱（除非是已经非常清晰成熟的领域）。另外，做技术架构的都有点完美主义倾向，一开始往往喜欢求大求全，忽视架构的演化和迭代性，这种倾向易造产品和用户之间不能形成有效快速的反馈，产品不满足最终用户需求。
其实，架构一直在演进、代码一直在重构，测试一直在优化，才是一个好的循环。
看看下面的这些，摘录了部分熟人云的描述(参考：http://doc.shurenyun.com/get-started/vocabulary.html)，部分文档如下：
微服务
微服务是一种新兴的应用软件架构，它通过一组服务的方式来构建一个应用，服务独立部署在不同的进程中，不同服务通过一些轻量级交互机制来通信，例如 REST。每个服务可独立扩展伸缩，并且定义了明确的边界，不同的服务甚至可以采用不同的编程语言来实现，由独立的团队来维护。
微服务架构有很多好处:
- 通过将巨大的单体式应用分解为多个服务,解决了复杂性问题。在功能不变的情况下，应用被分解为多个可管理的分支或服务。每个服务都有一个用 REST API 定义清楚的边界。微服务架构给采用单一编码方式很难实现的功能提供了模块化的解决方案，而单个服务很容易开发、理解和维护。
- 这种架构使得每个服务都可以由专门的开发团队进行开发。开发者可以自由选择开发技术，提供API服务。当然，许多公司试图避免混乱，只提供某些技 术选择。然后，这种自由意味着开发者不需要被迫使用项目初期所采用的过时技术，他们可以选择最新的技术。因为服务都是相对简单，所以即使用现在技术重写以 前代码也不是很困难的事情。
- 微服务架构要求每个微服务做到独立部署。开发者不再需要协调其它服务部署对本服务的影响。这种改变可以加快部署速度。微服务架构模式使得持续化部署成为可能。
- 微服务架构模式使得每个服务可以独立地扩展。你可以根据每个服务的业务量来部署满足其需求的规模。
服务发现
服务发现的基本思想是，任何一个应用的实例能够以编程的方式获取当前环境的细节，而新的实例可以嵌入到现有的应用环境而不需要人工干预。服务发现工 具通常是用全局可访问的存储信息注册表来实现，它存储了当前正在运行的实例或者服务的信息。大多数情况下，为了使这个配置具有容错与扩展能力，这个工具以 分布式形式存储在多个节点上。
服务发现减少或消除了组件之间的“手动”连接。当你把你的应用程序推送进生产环境的时候，所有的这些事情都可以配置：数据库服务器的主机和端 口，REST 服务的 URL 等等。在一个高可扩展的架构中，这些连接可以动态改变。一个新的后端可以被添加，一个数据库节点也可以被停止，你的应用需要适应这种动态环境。
数人云为用户提供了完备的服务发现能力：
- TCP/HTTP
根据服务端口协议的不同，可以选择 TCP 转发或 HTTP 转发； - 对内/对外
数人云不仅提供传统的对外服务发现，还为分布式服务提供了对内服务发现；对外服务发现通过外部网关对外提供服务，如果是 HTTP 服务，需要配置域名或外网 IP；对内服务发现通过内部代理，将多实例的微服务端口映射为统一暴露的端口；
示例
搭建 wordpress 站点的过程中，需要部署一个 Mysql server 和一个 Wordpress server。
- Mysql 本身的服务端口为3306，协议类型为 TCP；Mysql 服务需要对内部模块开放，开放端口仍然沿用3306。因此，对 Mysql 的应用地址配置如下所示。
数人云对内服务发现机制会自动将应用实例的地址映射为内部网关的地址。图中的“地址”一栏，即为访问 Mysql 所用的地址，其中 IP 为内部网关 IP。
- Wordpress 本身是一个 web 服务，其端口为默认 80，协议类型为 HTTP；Wordpress 服务需要对外部访问开放。
如果外部网关配有可访问域名，则通过域名访问服务，开放端口为 80，不可修改。
如果外部网关没有配置域名，则通过 IP 访问服务，开放端口可选，这里为防止端口冲突，设为81。
数人云对外服务发现机制会自动将应用实例的地址映射为外部网关的地址。图中的“地址”一栏，即为访问 Wordpress 所用的地址，其中 IP 为外部网关 IP或域名。
容器服务
容器采用沙箱机制，相互之间不会有任何接口（类似 iPhone 的 app），几乎没有性能开销，可以很容易地在机器和数据中心中运行。最重要的是，他们不依赖于任何语言、框架以及系统。
Docker是一个开源的应用容器引擎，让开发者可以快速打包应用以及依赖包到一个可移植的容器中，然后发布到任何主流的 Linux 主机上。
数人云采用目前流行的Docker容器，基于 Mesos 集群调度工具，能轻松管理和调度成千上万个容器，做到秒级启动，秒级销毁，并且能做到大规模的负载均衡。
数人云提倡客户采用微服务架构，将微服务架构应用的服务进行容器化，作为云计算应用交付的标准。这样的好处是，不仅能保持应用环境的一致性，让开发和运维等从烦杂的环境构建中解脱出来，还可以轻松做到容错性、高可用、横向扩展等特性。
借助熟人云快速大件Jenkins储蓄集成环境，测试人员可以用得到：
Jenkins
Jenkins 是基于 Java 开发的一种持续集成 (CI) 工具，使用数人云部署 Jenkins 能够在做到快速搭建的同时，实现资源的动态调度，提高资源利用率。
下面讲述一下数人云上搭建 Jenkins 的架构和工作流程：
- Jenkins Master
它负责提供整个 Jenkin 的设置、webui、工作流控制定制等。首先，将Jenkins-Master使用数人云发布，数人云会对其进行程序管理和健康检查，从而在应用程序由于 某些意外崩溃后自动恢复，保证了Jenkins-Master构建系统的全局高可用，使用数人云部署Jenkins使您的Jenkins应用运行在一个资 源池中，进一步实现了资源共享，提高了资源利用率。
- Jenkins Slave
Jenkins利用在数人云上建立的集群资源，主要的目的是利用弹性资源分配来提高资源利用率，通过配置Jenkins-mesos-plugin 插件，Jenkins Master可以在作业构建时根据实际需要动态的申请Jenkins-Slave节点，并在构建完成后的一段时间后，将节点归还。
- Jenkins-mesos-plugin
Jenkins-mesos-plugin是用插件模式挂载到Jenkins Master上的。主要目的是要把Jenkins-Master当作集群的调度器使用，可以调度用数人云建立的集群资源为Jenkins服务。
数人云注册&登录&创建集群
因为数人云迭代很快，所以这里就不进行详细描述，最新数人云操作文档会在数人云用户手册中，需要参考的用户请点击：数人云用户手册
使用数人云部署 Jenkins
部署 Jenkins 应用很简单，下面是具体操作步骤：
选择应用管理，点击"新建应用"，按照如下提示，新建 Jenkins 应用：
- 填写应用名称：jenkins
- 选择集群：demo
- 添加应用镜像地址：testregistry.dataman.io/centos7/mesos-0.23.0-jdk8-jenkins1.628-master
- 填写镜像版本：app.v0.3
- 选择应用模式：HOST模式
- 选择应用类型：有状态应用
- 选择主机：主机下拉列表中选择任一合适IP即可
- 主机/容器目录配置： 数据挂载目录：/data/jenkins 容器目录：/var/lib/jenkins
- 选择容器规格：CPU：0.2 内存：512MB
高级设置：
- 点击添加环境变量，填写环境变量参数：
Key: JAVA_OPTS Value: -Xmx512M -Xms512M key: JENKINS_PORT Value: 8002
填写完成之后，点击创建即可，创建完成后可看到应用部署状态等信息：
稍等片刻可看到应用已正常运行：
打开浏览器，在内部代理配置好的情况下访问 Jenkins，访问地址为：yourip:JENKINS_PORT，看到如下页面，则说明 Jenkins 应用已经成功运行。
Jenkins 数人云设置
如果我们想要将Jenkins作为mesos的一个framework注册到mesos上，需要在成功启动 Jenkins之后对其插件进行设置。
设置 Jenkins-Mesos 分三层，点击左上角"系统管理"，然后在系统管理页面点击"系统设置"。
- Jenkins 调用 Mesos 集群设置
- Mesos native library path 设置 Mesos lib 库路径，一般在/usr/lib/libmesos.so，拷贝无效，必须安装 Mesos。
- Mesos Master [hostname:port] 设置 Mesos-Master 地址加端口，如果单 Mesos-Master 模式，使用 mesos-master-ip:5050格式，如果是多 Mesos-Master 使用 zk://zk1:2181,zk2:2181,zk3:2181/mesos 格式
- Framework Name 设置 Mesos Master 查看到的应用框架名称
- Slave username 设置 Slave的名字
- Checkpointing 设置检查
- On-demand framework registration 设置是否在无任务的情况下，从 Mesos-Master 注销应用框架
- Jenkins Slave 调用 Mesos-Slave 类型设置(可按资源)
- Label String 设置 Slave 标签
- Maximum number of Executors per Slave 每个 Slave 可以同时执行几个任务
- Mesos Offer Selection Attributes 选择在那些 Mesos Slave 标签资源上运行，格式{"clusterType":"标签"}
- Jenkins Slave 调用 Docker 镜像设置
- Docker Image 设置 Jenkins Slave 使用镜像
- Networking - Bridge 设置网络模式，这里一定要设置网桥模式
- Port Mapping -Container Port & Host Prot 设置容器端口关系，必须设置否则会导致 Mesos-DNS 因找不到端口映射崩溃，Host Port 默认设置为空(自动取)，否则必须设置在39000以后的Mesos Slave 选定端口内。
- Volumes 挂载目录，必须挂载 slave.jar 和 docker in docker
后续
所使用的 Dockerfile 和启动脚本全部开源，并上传到熟人科技的GitHub，如果有兴趣的话，倒是可以参与一下，https://github.com/Dataman-Cloud/OpenDockerFile/tree/master/jenkins。
一个基于 Jenkins 的持续集成集群环境已搭建完成，让我们一起快速迭代产品吧，给用户不断带来一个个的小惊喜。