面向中小型客户的Saas云产品Devops建设总结
一、Devops概念
Devops（Development and Operations）是一组过程、方法与系统的统称，用于促进开发、运营和技术保障部门之间的协作沟通与整合，可以避免开发人员与运维人员产品沟通、工作流程的脱节。
二、交付背景
1.客户分布
本产品定位为行业解决方案，主要面向客户范围为全国各地，单个客户的系统使用人数为500-2000人。会出现部分模块定制化开发或业务流程调整的情况，因此需要进行较为频繁的版本迭代，并能在效率较高的情况下尽量减少成本预算和开销。
2.远程运维愿景
由于存在客户群体大、分布地区多样、版本发布频繁的需求存在，因此需要可以实现远程运维，能在单点控制多个客户现场。
如下图所示：
（1）服务资源最终会托管给云供应商，研发团队通过访问IP的方式对云主机进行操作
（2）云供应商会对访问IP进行权限控制，保障只对用户内网提供系统使用
（3）用户在使用过程中如果出现问题或者建议，可以向研发运维团队反馈，并进行远程支持维护
三、技术背景
1.开发技术栈
服务端采用了微服务分布式架构，与传统架构相比，分布式架构更好地解决了服务器性能问题，利用多节点的更强处理能力，提高系统的整体性能。在业务方面，将系统拆分成多个业务单元，让模块之间高内聚低耦合，降低业务的复杂度。同时，在部署方面，可以根据各个模块的使用特点，合理的分配资源，如基础数据模块，可以更多地分配云资源，保证面向较大并发量时的稳定性。
2.Devops工具链
| 用途 | 名称 |
|---|---|
| 代码管理(SCM) | Gitlab |
| 持续集成 | Jenkins |
| 构建工具 | Maven |
| 包(镜像)管理 | Npm、Nexus、Harbor |
| 镜像 | docker |
| 代理+web服务器 | Ngnix、Haproxy |
| 脚本语言 | shell |
| 日志采集 | Elasticsearch、Logstash、Kibana |
| 链路追踪 | Zipkin |
| 服务监控 | Prometheus |
四、发布流程
1.持续集成
持续集成（Continuous integration）是一种软件开发实践，即团队开发成员经常集成他们的工作，通常每个成员每天至少集成一次，也就意味着每天可能会发生多次集成。每次集成都通过自动化的构建（包括编译，发布，自动化测试）来验证，从而尽早地发现集成错误。本产品持续集成部分主做了如下工作，如下图所示：
（1）开发人员将自己在本地开发好的代码提交并合并到指定的分支，接着会触发Jenkins的pipeline（PS：由于代码管理模式没用到fork，因此没有在merge request时进行代码测试）
（2）Jenkins会按照设定好的步骤进行基础环境进行检测，判断是否可以进行下一步构建工作。紧接着会对新的代码版本进行代码检查、build、单元测试
agent {
docker {
image 'node:latest'
}
}
（3）以上流程都通过以后会将代码上传到版本库当中（Nexus、Harbor），如果中途没有通过，会将错误日志Email发送到相关人员的邮箱中
post {
failure {
updateGitlabCommitStatus name: 'complete', state: 'failed'
emailext attachLog: true,
2.持续交付
持续交付（Continuous delivery），是一种软件工程手法，让软件产品的产出过程在一个短周期内完成，以保证软件可以稳定、持续的保持在随时可以发布的状况。它的目标在于让软件的构建、测试与发布变得更快以及更频繁。这种方式可以减少软件开发的成本与时间，减少风险，流程图下图所示：
（1）Jenkins根据指定的包版本号从nexus仓库中取出对应版本的包，并压缩发送到跳转服务器（跳转服务器的存在为了解决公司内网和云之间的网络问题）
（2）通过Jenkins远程触发测试环境的更新脚本,并执行多个步骤。
a)从跳转服务器获取压缩包
b)执行解压
c)替换新的版本包到指定目录下
d)停止原有进程，启动新的进程
e)进程检测
f)测试环境发布完成
（3）开发测试人员对新的版本进行确认，并启动自动化测试工具（selenium）进行测试
（4）在生产环境指定步骤2的基本操作流程
（5）通过Prometheus、ELK、ZIPkin等工具对服务和软件信息进行记录和监控
五、云端部署架构
使用LVS、Nginx反向代理、微服务结点多活，数据库RAC，对集群实现多层负载均衡。
