开发为什么要从零开始搭建属于自己的统一研发平台和中台架构

updown

从零开始搭建的意思，就是从需求分析，系统规划，设计分析和落地实践几个步骤，从无到有的过程。考虑左右，为了个人学习和提升，选型基于流行的springboot+springcloud，从零开始搭建一套自己用于学习的研发平台。

整体平台的流程，从管理、开发、测试、运维、生产几条线，实现整体平台的落地和管理，下面是整体研发平台架构。

整个研发平台架构设计

整体研发平台使用的基线规划如下

平台所有基线及所有项目目录结构，整体从零开始进行平台基线搭建及规划，多个基线的规划，考虑更合适多个岗位角色的管理

[td]

序号	基线说明	基线地址	维护人员	状态	备注
1	平台整体文档目录	alinesno-cloud-document		集成中
2	平台环境搭建文档记录文档基线	alinesno-cloud-evn		集成中
3	平台前端规划及页面基础页面设计基线	alinesno-cloud-pages		集成中
4	平台所有服务列表代码基线	alinesno-cloud-service		集成中
5	平台前端应用和手机应用代码基线	alinesno-cloud-application
6	平台自动化测试基线	alinesno-cloud-test
7	平台运维脚本过程产物基线	alinesno-cloud-operation
8	平台搭建过程中常见问题基线	alinesno-cloud-question
9	开发人员使用平台指引	alinesno-cloud-guide			略

; ?, X# B9 |, w" e0 C# T1 X一、个人为什么要搭建一个统一研发平台

1、为了有方向感，不迷茫，不浪费时间，有可行的学习计划

上大学的时候，就开始学习计算机，从基础的Java到Java web，再到框架，再到在学校接一些小项目，如企业网站，兼职网，报名网站等，这几步路大概走了2年左右，而在学完两年之后，人还是很迷茫，方向感还不是特别强，而在找方向和突破迷茫上面，走过了很多弯路，终于找到点方向。后来才发现，很多这个专业的同学，可能毕业几年之后，依然还找不到方向和定位，东学一点西学一点，很浪费时间，可能醒悟的时候，已经过了3~5年，很难再转回头。

2、为了在工作和学习过得中不断积累和提高学习效率

学习和工作的几年里，几乎每个项目，资料，文档，规范都是有共性的，而由于各个项目的不统一，在接收新项目的，几乎都从零开始，一些非功能性需求的建设已经占去了实际项目的很多时间，投入需求建设的时间其实没多少，最简单的，代码的CURD都是一样，自己在做的时候，针对每个项目都有改进，比如这个项目统一了CURD，那个项目梳理出了公共代码，但是项目是分开的，最终新的项目，也是从零开始或者复制，再加上人工，手工，人肉运维，不断的繁琐而简单的工作的学习中无法脱身，影响进入下一步学习。这类似于温水煮青蛙，没有感觉，可能慢慢拖死自己，特别是做项目的前两年，除了数据的添加删除，还是这些。重复开发，无法共用这些都消耗了很长的时间。比如一直想学大数据，但是由于没有好的平台依托，目前还是无法投入学习。

3、为了可以总结和反思，可以不断的打磨出一个平台，一个产品或者一个精品

这几年的工作和学习中，有很多都是在学习，在努力，也很上进，资料有不计其数，但是却在用的时候，没有深入或者精通某一个模块，最常见的，连自己精通的模块都无法界定，不自信，没有自己的深入心得，比较浮在表面上。自己近乎有两年的状态如此，一直在努力，但是却一直没有达到预期的，别人认可的效果，接触的面好像很多，但是却没有哪一样是完全吃透的。最终发现的原因是没有做好总结和复习，反思，一个知识点以为看过了就懂，但是没有结合实际进行提炼与打磨，没有吃透，就往下一个模块，最终导致好像不断的在捡东西，但最终这些东西都不是自己的。所以需要打磨自己的东西，能谈出自己心得，这就是自己的产品，就是自己的精品，或者自己就一个精品。

4、为了扩大自己的视野和学习心态，开放心态

学习中最怕和就是无沟通与交流，没有他人的指点和自己的固步自封，坐井观天等心态，在学得一些技术之后，开始自以为自，然后偏向于安逸。明显，这种心态自己曾经有过，而且持续很长一段时间。这间接造成不管是沟通、技术方面都慢慢出现问题。自己一直相信，心态有多开放，有多宽容，帮助的人越多，自己也才更好的成长，不管是技术还是管理，包括生活等。

二、个人需要搭建怎么样的研发平台来学习

1、可以随时随地的学习，只要有网络和电脑，就可以学习

闲碎的时间常常存在，比如学校上机，看手机，还有一些无聊的聚会，甚至上厕所，这些都要能可以用来学习，网络现在无处不在，有个手机就可以上网，所以这些时间要能充分利用起来。

2、可以好的工具和学习环境

学习过程，工具的成熟度和熟练程度很多时间影响到自己的学习效率。比如vim的配置使用，熟练之后，不管在编辑和代码方面，速度都比一般的操作快得多。还有jenkins，在这个工具上不断的学习和积累，不管是配置和权限，发布，运维，分布式都能很大的帮助，同时节省很多时间。

3、可以不断的学习目标，最好从基础程序员到总监

学习有一个从零开始，到不断往上的过程，并且有目标，知道每个目标阶段需要什么样的技术，能力，成长时间等，做到心知肚明，不浪费多余时间 。可以不断的有学习积累，在积累上由量变到质变

5、可以不断的跟外界沟通交流，避免闭门造车，固步自封

需要不断的与外部学习，获取到外部的建议，看到自己的不足，同时也看到自己的优点。在自己不断学习的过程中，同时不断的成果，并让别人看到，给自己提建议，在自己把自己的思路成果对外贡献的同时，别人也一样帮自己提升。

三、研发平台怎么搭建，搭建到什么样的程度

搭建的思路都是先有一稿，然后再后期慢慢在这一稿上面做好优化，同时参考当前社会主流技术，便于学习。

1、制定整体学习规划和学习路线，技术路线和成长规划

平台构建过程中，产生大量的技术产物和管理产物，而在大量的项目过程中，同时也会产生大量的问题导致过程中细节的不完善，人为的不完善及限制，导致平台无法正常管理和运维，开发平台的管理规划即针对整体平台的运维管理进行的建议，以达到管理统一有序，过程明确，产物明确，目标明确等

从需求->准备->组织->开发<->内部测试<->用户测试<->自动测试->生产(试运行)->生产->运维整个流程完善，每个流程中又包括多个工作，如需求管理，同时每个工具必然有一定的产物，如需求管理的产物是需求管理基线和需求文档。

[td]

序号	模块	功能	产物	备注
1	需求	需求管理	管理基线
2	需求	组织分工	需求人员管理表
3	需求	需求变更
4	需求	需求确认	需求文档
5	需求	需求分配
6	准备	工具准备	工具管理文档
7	准备	组织结构	人员资源清单
8	准备	环境准备	开发基线/文档管理基线
9	准备	资源准备
10	准备	基线准备
11	组织	人员资源	人员资源准备
12	组织	开发管理
13	组织	沟通管理
14	组织	角色分工	角色分工及联系沟通表
15	组织	版本管理
16	开发	开发培训
17	开发	开发管理
18	开发	单元测试
19	开发	开发流程
20	开发	部署管理
21	开发	问题处理
22	测试(内部)	内部测试
23	测试(内部)	组织机构
24	测试(内部)	问题反馈
25	测试(内部)	Bug管理
26	测试(内部)	接口测试
27	测试(内部)	功能测试
28	测试(内部)	集成测试
29	测试(用户)	业务测试
30	测试(用户)	问题反馈
31	测试(用户)	Bug管理
32	测试(用户)	问题反馈
33	测试(用户)	测试报告
34	测试(用户)	版本管理
35	测试(自动)	测试配置
36	测试(自动)	压力测试
37	测试(自动)	安全扫描
38	测试(自动)	功能测试	测试报告
39	测试(自动)	安全测试	安全报告
40	测试(自动)	压力测试	压力报告
41	生产(试运行)	切换计划
42	生产(试运行)	工单管理
43	生产(试运行)	账号管理
44	生产(试运行)	安全管理
45	生产(正式)	运维监控
46	生产(正式)	工单管理
47	生产(正式)	日志管理

为达到以上的要求，也为了过程有记录和沉淀，考虑一些必要性的管理工具，暂时考虑以下几个工具：

[td]

序号	说明	技术	版本	备注
1	文档管理	GitBook		企业内部做好考虑，团队未必每个人都能接受markdown
2	Wiki管理	GitBook		企业内部做好考虑，团队未必每个人都能接受markdown
3	开发过程管理	Jira
4	开发工具管理	百度网盘		公司内部建议使用FTP或者内部文件系统
5	邮件通知	163邮箱		建议使用企业内部邮箱

以下为文档管理基线示例

2、制定持续集成环境，为学习提供基础的准备和提升效率

持续集成他一套比较成熟的自动化研发解决方案，使用也有几年时间，不同的人有不同的设计，有些可能只是发布工程，这里针对于需求、开发、测试、文档、运维几个维度，进行了整合，同时也制定和管理方案，以达到基础规范 – 组织结构 – 基础架构 – 业务开发 – 持续集成– 自动化部署 – 自动化测试 – 生产运维监控 – 在线升级 几个方向自动化，这里不得不提一下Jenkins+git，确实是整个自动化的核心。目前考虑了一下这些工具，针对于开发的：

[td]

序号	说明	技术	版本	备注
1	代码管理	Git(gitee)	2.17.1	企业内部建议使用gitlab(更能满足需求)
5	代码管理客户端	SourceTree	2.7.6
2	自动部署工具	Jenkins	2.107.1	不建议使用太新版本
3	私服库	Nexus	2.14.1	不建议使用3.x版本
3	构建工具	Maven	3.6.0
4	代码检测	Sonar	5.x	不建议使用太新版本
5	镜像管理	Harbor	1.5.2
6	镜像容器	Docker	1.12.1
7	容器管理	Kubernetes	1.10	不建议使用太高版本,跟着社区走

$ d; e/ a! V2 q

自动化持续集成的效果如下：

文档持续集成效果如下:

3、下载和整理软件工具，整理软件工具版本

基础环境完善及配置，为整个开发平台做基础，以环境搭建为主,为本地开发环境。

使用的阿里云服务器规划如下：

[td]

序号	作用	服务器资源(系统/内存/硬盘)	IP规划	备注
1	开发服务器_master	CentOS7.4_x64_4G_40G	192.168.1.110
2	开发服务器_slave	CentOS7.4_x64_2G_40G	192.168.1.111
3	开发服务器_slave	CentOS7.4_x64_1G_40G	192.168.1.112

% T9 Q! f" K$ O1 _( o  J

规划的使用工具如下：

[td]

序号	说明	工具	IP	是否集群	文档完善进度	备注
1	基础环境	JDK	172.18.11.17	单点	已完善
8	反向代理	Nginx	172.18.11.17	单点	已完善
11	自动部署工具	Jenkins	172.18.11.17	单点	完善中
12	私服库	Nexus	172.18.11.17	单点	已完善
17	链接跟踪	skywalking	172.18.11.17	单点
13	代码检测	Sonar	172.18.11.17	单点
2	缓存工具	Redis	172.18.11.17	单点	已完善
4	消息列表	Kafka	172.18.11.17	单点	已完善
10	分布式注册中心	zeekeeper	172.18.11.17	单点	完善中
6	分布式注册中心	Eurake	172.18.11.139	单点
10	分页式配置中心	Apollo	172.18.11.139	单点
6	数据库	MySQL	172.18.11.139	单点	已完善
1	开发过程管理	Jira	192.168.1.120	集群
3	Redis监控工具	Redmon	192.168.1.119	单点
5	消息管理工具	Kafka-Manager	192.168.1.119	单点
7	数据库主从	MyCAT	192.168.1.111/112	集群
7	容器管理	Kubernetes	192.168.1.1110/111/112	集群
9	高可用	KeepAlived	192.168.1.110/111/112	集群
14	镜像管理	Harbor	192.168.1.110	单点
15	自动部署	Ansible	192.168.1.119	单点
16	自动部署管理	Ansible Tower	192.168.1.119	单点
17	链接跟踪	pinpoint	192.168.1.119	单点
18	日志监控	elk	192.168.1.119	集群
19	服务器监控	Zabbix	192.168.1.119	单点

2 R4 h1 h5 ^* c- f$ p( k

工具的保存是放在百度云上面：

4、规划平台非功能性需求组件，包括基础组件等

功能重用，组件重用，目前最好的技术承载就是微服务了，这也是这几年才出现，这样规划研发平台构架，对我而言，微服务架构自然成为不二的选择（后面的中台业务也是在微服务上进行进程创建）

服务设计原则

服务单库设计,以减少迁移，服务之前影响等；
+ h# F# f& p" D/ K" T$ E* G& g& O基础服务只为调用设计，位于服务的底层或者中间层，基础服务禁止调用业务服务；
  O! U  G! J) w7 k" ^9 D) S# ~& {业务服务调用基础服务，或者其它服务，业务服务为服务的顶层，用于定制化业务；
同一级服务之间可以互相调用，只能自下往下调用，平级调用，禁止自下往上调用，以避免服务混乱及维护混乱。
+ f: c. l- g# W每种服务目录按999个服务规划

服务设计规划

[td]

类型	目录名称	说明	备注
教程	示例服务	做示例工程，包含有所有服务调用示例
前端应用	门户服务	与中台服务同级，用于统一门户服务
前端应用	应用服务	前端应用或者手机应用
网关应用	网关服务	对外网关服务,与平台组件同级，但仅做为网关部分
中台服务	中台服务	服务于前端应用，处理业务，可以服务之间互相调用，或者调用基础服务
基础服务	基础服务	公用基础组件，只能被调用或者调用公共或者组件包,不能主动调用其它服务
基础服务	公共服务	基础公共包,所有工程的基础，包括配置，页面，核心包等
基础服务	组件服务	基础组件包，用于第三方等，组件包不能单独运行，只能被依赖
运维环境	监控服务	监控平台，用于运维平台，目前仅规划,有可能与平台服务合并一起
运维环境	平台服务	包括注册中心，配置中心等

工程目录规划

关于命名方向，一直不知道用什么名字比较合适，所以使用自己网站的域名。

[td]

序号	目录名称	目录规划	端口规划	权限	备注
1	公共服务	alinesno-cloud-common		研发
2	组件服务	alinesno-cloud-component		研发
3	平台服务	alinesno-cloud-platform	24000+	研发
4	基础服务	alinesno-cloud-base	25000+	研发
5	业务服务	alinesno-cloud-business	26000+	开发
6	门户服务	alinesno-cloud-portal	27000+	研发
7	网关服务	alinesno-cloud-gate	28000+	开发
8	应用服务	alinesno-cloud-web	34000+	开发
9	监控服务	alinesno-cloud-monitor	35000+	研发
10	示例服务	alinesno-cloud-demo	30000+	研发	置于guide基线

+ {4 _- @3 @8 N

5、提取出业务中台规划，并完善组件，打磨中台业务产品

上面也提到，业务中台也是在微服务上面构建，设计原则加上了几个点，分别如下：

按“重中台”+”轻应用”设计，业务应用逻辑思路放在前端应用，推荐是尽量减少或不拆分前端服务;
重中台的建设，在于前端应用共性部分的抽取和后期的沉淀，形成中台业务服务;
4 x" f/ L% r8 [9 d; @9 [( ]- X中台服务调用基础服务，或者其它同级服务，中台服务为服务的中层，用于业务共性(共享)抽取；

整体中台的业务架构如下：

中台业务架构设计

中台业务建设目标如下

中台业务建设目标

6、统一和通用的权限配置系统和界面设计

这个就是通用的，只需要在配置平台添加好菜单，分配好账号权限，本地开发只需要账户就可以进行本地开发，配置平台包括的一些功能规划如下：

应用管理：用于配置系统应用，添加和删除管理。
9 Z$ j. F( ^0 e, q) c用户管理：用户是系统操作者，该功能主要完成系统用户配置。
' z( g# b4 G( `' n部门管理：配置系统组织机构（公司、部门、小组），树结构展现支持数据权限。
0 D, N. k7 c8 w岗位管理：配置系统用户所属担任职务。
# l4 P" o* }) m/ V* l菜单管理：配置系统菜单，操作权限，按钮权限标识等。
) ?4 }) f4 j$ a角色管理：角色菜单权限分配、设置角色按机构进行数据范围权限划分。
字典管理：对系统中经常使用的一些较为固定的数据进行维护。
参数管理：对系统动态配置常用参数。
通知公告：系统通知公告信息发布维护。
6 O; K9 Q1 h8 k2 u- {2 {操作日志：系统正常操作日志记录和查询；系统异常信息日志记录和查询。
登录日志：系统登录日志记录查询包含登录异常。
在线用户：当前系统中活跃用户状态监控。
定时任务：在线（添加、修改、删除)任务调度包含执行结果日志。
( o6 {' W8 @* L8 O) x代码生成：前后端代码的生成（java、html、xml、sql)支持CRUD下载 。

然后大概的设计如下：

开发人员的开发流程如下：

7、完善软件组件辅助，包括测试、运维、环境管理

以上组件的搭建过程，如果一个人管理，会产生很多问题，同时延伸出其它方向的建设，其中包括最基础的服务器管理和服务预警方向，安全策略管理，平台整体入口和常用文档，功能，平台组件的质量保证，即运维、机房环境，测试这几块。在建设统一研发平台的同时，也自然包括建设这些内容，大概做了一些建设工作，以下为一些设计的示例。

机房服务器管理系统

机房管理系统，针对云系统和服务部署的管理

平台统一门户管理

• 
  5 Z# [, K; O. |1 n- ~% j

其它的建议，如包括人才培养，大数据，人工智能，项目管理，都是在研发平台中慢慢积累和培养的产物，而最终的结果是为了整理出一套完整的企业统一研发平台。

四、总结

以上为目前搭建整体个人整体研发平台的思路和设计，一个优秀的研发人员的工作并非只是编制代码，更多的是自己能做什么，完成什么，有什么价值，能帮别人做什么。

love1

学习和工作的几年里，几乎每个项目，资料，文档，规范都是有共性的，而由于各个项目的不统一，在接收新项目的，几乎都从零开始，一些非功能性需求的建设已经占去了实际项目的很多时间，投入需求建设的时间其实没多少，最简单的，代码的CURD都是一样，自己在做的时候，针对每个项目都有改进，比如这个项目统一了CURD，那个项目梳理出了公共代码，但是项目是分开的，最终新的项目，也是从零开始或者复制，再加上人工，手工，人肉运维，不断的繁琐而简单的工作的学习中无法脱身，影响进入下一步学习。这类似于温水煮青蛙，没有感觉，可能慢慢拖死自己，特别是做项目的前两年，除了数据的添加删除，还是这些。重复开发，无法共用这些都消耗了很长的时间。比如一直想学大数据，但是由于没有好的平台依托，目前还是无法投入学习。