创业公司自动化上线的架构设计

导语：

晚上听了58沈剑老师的自动化上线的课程的一些分享，记录下笔记和一些思考，这要是讲了从创业公司的手动发布到自动化发布的架构和设计。

1.起源

问题的提出：如何把新系统发布到线上？

不同公司的阶段有着不同的策略和方式如下图：

对于创业公公司来说对于研发工程师往往是多面手，很多时候部署就是自己操作的。
发布代码非常繁琐和麻烦，工程师会花费大量的时间在这些重复性的劳动上面。这里就是问题的所在，
应该解放工程师去做更多有意义的事情，从重复性劳动中解脱出来。

2.创业公司会遇到的困难

困难如下图：

创业公司可能技术栈比较单一，语言这方面不会太多，但是沈老师说的领导不重视这一点倒是很有可能发生。
上头只看结果，不在意系统发布怎么快怎么优化，这时候应该负责任把方案拿出来，说可以用很少的时间，很大的提高
研发的开发效率，这个时候可能才会比较容易争取到上司的同意和资源协调。
具体可以列举的理由（自动化发布要实现的功能）：
1.解决大部分需求
2.支持多语言
3.支持多类型上线：web，service
4.支持多框架上线
5.可以定制化
6.能够快速落地

3.自动化上线实践

3.1 抽象集群：
前提需要抽象集群，集群是保证高可用的基础

3.2 集群信息：
例如：一个用户服务集群有哪些信息？

3.2.1 集群信息的作用
a.上下游调用：
举例：web-X调用user.service会用到哪些信息?
上下游调用会用到的集群信息：
service.name:user.service
service.ip.list:ip1,ip2,ip3
service.port:8080
(这些信息保存在web-X.config)

上下游调用过程：
web-X启动
web-X读取服务器ip列表和端口
web-X初始化服务连接池
web-X拿取连接，进行rpc接口调用

b.自动备份二进制文件
举例：自动化备份会用到哪些信息？
自动化备份会用到的集群信息：
service.name：user.service
service.ip.list:ip1,ip2,ip3
bin.path: /user.service/bin
(这些信息保存在backup.user.service.config)

自动化备份的过程：
1.依次轮询每个ip
2.建立相关备份目录
3.把二进制复制到备份目录下

3.2.2 集群信息的维护
集群信息的维护分为两种，分散式和集中式。如图：

集中式集群配置，是自动化上线的基石。
集中式发展：全局的配置文件->配置服务->配置中心

4.抽象自动化上线过程

过程抽象如图：

每个集群增加一个cluster.type集群类型，用来标识集群是干嘛的。
比如分三级cluster.type=Java.web.SpringMVC
第一级是标识语言种类
第二级是标识是web还是service的类型
第三级是标识使用的是什么框架（不同的框架发布方式不一样 ）

4.1 集群自动初始化化举例

Java.web.Spring: 部署tomcat，部署相关库，建立规范的目录结构
Java.service.dubbo: 部署容器，部署相关库，建立规范的目录结构
C++.service.sofa: 部署相关库，建立规范目录结构
PHP.web.zend:...

综上所述，每个集群的类型有着固定的初始化过程。

4.2 规范目录结构
规范目录结构很重要，只有规范好固定的结构，才能写对应的脚本去做出相应的处理。
如图：

4.3 日志规范
日志规范是日志自动化监控/备份/清理的基础
如图：

4.4 集群的构建+打包自动化举例

PHP:copy+tar相关代码
Java：Maven
C++：Make

4.5 集群发布自动化举例
以java.web.DWF,如图：

4.6 回顾整个流程
如图：

4.7 自动化到平台化
如图：

5.架构思路和总结

架构思路：

**1.中心化管理：保证数据一致
2.抽象：提供共性的地方，尽量通用
3.分解：整理很复杂，分支很简单
4.可扩展：通过service_type保持个性可扩展**

总结:

**1.架构设计，讲究抽象，将复杂的问题透析成简单的问题
2.统一规范很重要，只有大家都统一了规范（日志规范，代码规范，目录规范...），才能做更多的事情，比如就像今天说的自动化发布，如果不规范统一，
就很难自动化，因为个性的东西太多了没法用通用的手段去处理。
3.实现步骤要一步步来，人肉->自动化->平台化，不是一蹴而就的，要对应公司目前的发展一步步来，找到最适合自己公司业务发展的方式。**