EDA365欢迎您登录!
您需要 登录 才可以下载或查看,没有帐号?注册
x
一、个人为什么要搭建一个统一研发平台1、为了有方向感,不迷茫,不浪费时间,有可行的学习计划 上大学的时候,就开始学习计算机,从基础的Java到Java web,再到框架,再到在学校接一些小项目,如企业网站,兼职网,报名网站等,这几步路大概走了2年左右,而在学完两年之后,人还是很迷茫,方向感还不是特别强,而在找方向和突破迷茫上面,走过了很多弯路,终于找到点方向。后来才发现,很多这个专业的同学,可能毕业几年之后,依然还找不到方向和定位,东学一点西学一点,很浪费时间,可能醒悟的时候,已经过了3~5年,很难再转回头。 2、为了在工作和学习过得中不断积累和提高学习效率 学习和工作的几年里,几乎每个项目,资料,文档,规范都是有共性的,而由于各个项目的不统一,在接收新项目的,几乎都从零开始,一些非功能性需求的建设已经占去了实际项目的很多时间,投入需求建设的时间其实没多少,最简单的,代码的CURD都是一样,自己在做的时候,针对每个项目都有改进,比如这个项目统一了CURD,那个项目梳理出了公共代码,但是项目是分开的,最终新的项目,也是从零开始或者复制,再加上人工,手工,人肉运维,不断的繁琐而简单的工作的学习中无法脱身,影响进入下一步学习。这类似于温水煮青蛙,没有感觉,可能慢慢拖死自己,特别是做项目的前两年,除了数据的添加删除,还是这些。重复开发,无法共用这些都消耗了很长的时间。比如一直想学大数据,但是由于没有好的平台依托,目前还是无法投入学习。 3、为了可以总结和反思,可以不断的打磨出一个平台,一个产品或者一个精品 这几年的工作和学习中,有很多都是在学习,在努力,也很上进,资料有不计其数,但是却在用的时候,没有深入或者精通某一个模块,最常见的,连自己精通的模块都无法界定,不自信,没有自己的深入心得,比较浮在表面上。自己近乎有两年的状态如此,一直在努力,但是却一直没有达到预期的,别人认可的效果,接触的面好像很多,但是却没有哪一样是完全吃透的。最终发现的原因是没有做好总结和复习,反思,一个知识点以为看过了就懂,但是没有结合实际进行提炼与打磨,没有吃透,就往下一个模块,最终导致好像不断的在捡东西,但最终这些东西都不是自己的。所以需要打磨自己的东西,能谈出自己心得,这就是自己的产品,就是自己的精品,或者自己就一个精品。 4、为了扩大自己的视野和学习心态,开放心态 学习中最怕和就是无沟通与交流,没有他人的指点和自己的固步自封,坐井观天等心态,在学得一些技术之后,开始自以为自,然后偏向于安逸。明显,这种心态自己曾经有过,而且持续很长一段时间。这间接造成不管是沟通、技术方面都慢慢出现问题。自己一直相信,心态有多开放,有多宽容,帮助的人越多,自己也才更好的成长,不管是技术还是管理,包括生活等。 二、个人需要搭建怎么样的研发平台来学习1、可以随时随地的学习,只要有网络和电脑,就可以学习 闲碎的时间常常存在,比如学校上机,看手机,还有一些无聊的聚会,甚至上厕所,这些都要能可以用来学习,网络现在无处不在,有个手机就可以上网,所以这些时间要能充分利用起来。 2、可以好的工具和学习环境 学习过程,工具的成熟度和熟练程度很多时间影响到自己的学习效率。比如vim的配置使用,熟练之后,不管在编辑和代码方面,速度都比一般的操作快得多。还有jenkins,在这个工具上不断的学习和积累,不管是配置和权限,发布,运维,分布式都能很大的帮助,同时节省很多时间。 3、可以不断的学习目标,最好从基础程序员到总监 学习有一个从零开始,到不断往上的过程,并且有目标,知道每个目标阶段需要什么样的技术,能力,成长时间等,做到心知肚明,不浪费多余时间 。可以不断的有学习积累,在积累上由量变到质变 5、可以不断的跟外界沟通交流,避免闭门造车,固步自封 需要不断的与外部学习,获取到外部的建议,看到自己的不足,同时也看到自己的优点。在自己不断学习的过程中,同时不断的成果,并让别人看到,给自己提建议,在自己把自己的思路成果对外贡献的同时,别人也一样帮自己提升。 三、研发平台怎么搭建,搭建到什么样的程度搭建的思路都是先有一稿,然后再后期慢慢在这一稿上面做好优化,同时参考当前社会主流技术,便于学习。 1、制定整体学习规划和学习路线,技术路线和成长规划 平台构建过程中,产生大量的技术产物和管理产物,而在大量的项目过程中,同时也会产生大量的问题导致过程中细节的不完善,人为的不完善及限制,导致平台无法正常管理和运维,开发平台的管理规划即针对整体平台的运维管理进行的建议,以达到管理统一有序,过程明确,产物明确,目标明确等 从需求->准备->组织->开发<->内部测试<->用户测试<->自动测试->生产(试运行)->生产->运维整个流程完善,每个流程中又包括多个工作,如需求管理,同时每个工具必然有一定的产物,如需求管理的产物是需求管理基线和需求文档。 序号 模块 功能 产物 备注 ( U& G* ?% B% Q
1需求需求管理管理基线
, {& ]1 l1 P+ s- Z( j2 D: ` i( w2需求组织分工需求人员管理表
# m7 G8 [( t8 G/ a3 l1 T3需求需求变更 + H. V& ~( n+ h/ u) p2 G5 r! t$ ~
4需求需求确认需求文档 0 K, ?1 g' C/ t1 o, H! g& W
5需求需求分配
" o4 ~- d8 u; m6准备工具准备工具管理文档 ' `/ r x; K$ W7 H7 n
7准备组织结构人员资源清单 $ N. b6 Y9 F1 K9 I# n# ]" N
8准备环境准备开发基线/文档管理基线
% R. ? u0 L$ ?3 N7 B9准备资源准备
7 _3 S3 G b/ D* ]! [" d10准备基线准备
/ Y3 C& e* O$ a+ u; L/ [% F' t- |$ c11组织人员资源人员资源准备
' ~) i9 n* u# y# @/ ?2 W12组织开发管理
4 H3 q) I/ f7 r4 i: o6 b" c. ]) E13组织沟通管理 ' P$ @( ?' ?' e, U3 W# ^
14组织角色分工角色分工及联系沟通表
" }; L3 p; ~6 a8 {; Z& d) S1 [15组织版本管理
- K1 H4 I$ T7 e, E4 u16开发开发培训 g; K2 M O: P* M" G, z* }
17开发开发管理
2 S) X0 b! R2 m3 p18开发单元测试 2 ?8 L4 ?! i) H2 i
19开发开发流程 % I; t* M/ x0 B) G8 D* i
20开发部署管理
# U. `) U$ o: @& w! K21开发问题处理
4 B) W* w# _2 X# t, J2 `22测试(内部)内部测试 $ ?( K1 ^+ C% J4 J9 |# c
23测试(内部)组织机构 + B+ ]7 S0 s; A w( L
24测试(内部)问题反馈 . c/ d( f; g2 ^5 h4 c
25测试(内部)Bug管理
( T1 ]; f. w+ F# Z$ I+ F26测试(内部)接口测试
& h& u7 b0 x6 z ^, n, t27测试(内部)功能测试 + b$ o- K, k9 r1 z$ P) ^
28测试(内部)集成测试
3 {* L7 O6 ]. u" L, o29测试(用户)业务测试 ! D5 y% r+ K% v% j/ ~
30测试(用户)问题反馈
. V0 [! f0 D# {! w31测试(用户)Bug管理 4 b8 B* v1 m, b. N$ y
32测试(用户)问题反馈
2 z( L z2 P7 W* B) n4 i2 @33测试(用户)测试报告
' X* M. B; o8 D6 Z; {34测试(用户)版本管理
- W0 J+ e( P! W( ~1 P4 |! W( U35测试(自动)测试配置
. R; \" s9 o( I) A1 \36测试(自动)压力测试
4 K, {( ~# L3 K1 [/ Y# D/ G37测试(自动)安全扫描 7 |6 ]% U" b4 r a6 y
38测试(自动)功能测试测试报告
, G' i" k8 G) O39测试(自动)安全测试安全报告
; ?4 a! Q& n1 N) ?7 k1 w40测试(自动)压力测试压力报告
~8 ^2 ~$ z2 }$ O- g' v' z41生产(试运行)切换计划
; p+ I# K- |9 U% |- K* @1 J42生产(试运行)工单管理
% Q7 Y& L. {$ j. j0 _43生产(试运行)账号管理 2 Y! H/ x! ]) X6 y& C5 _" O8 C
44生产(试运行)安全管理 + F( ] M7 O" Z/ B4 a4 {0 W
45生产(正式)运维监控 + A7 v) Y3 }0 h# E- V# i$ _' w
46生产(正式)工单管理
1 r8 v, N1 @) N+ K" g* q+ D2 F# G47生产(正式)日志管理
# ~) ?5 ^ j" i! u5 ?, z+ [: A为达到以上的要求,也为了过程有记录和沉淀,考虑一些必要性的管理工具,暂时考虑以下几个工具: 序号 说明 技术 版本 备注
" K3 }; M, c, v+ y9 S3 f; ^1文档管理GitBook 企业内部做好考虑,团队未必每个人都能接受markdown: }) [* P3 E# H: O+ j6 P& ~
2Wiki管理GitBook 企业内部做好考虑,团队未必每个人都能接受markdown" x& O/ s1 P. c
3开发过程管理Jira 5 l, S( T2 p5 R* H; j
4开发工具管理百度网盘 公司内部建议使用FTP或者内部文件系统9 D3 U+ {2 U* `' f
5邮件通知163邮箱 建议使用企业内部邮箱( L' [: z0 w: ]& g) {
以下为文档管理基线示例 ![]()
2、制定持续集成环境,为学习提供基础的准备和提升效率 持续集成他一套比较成熟的自动化研发解决方案,使用也有几年时间,不同的人有不同的设计,有些可能只是发布工程,这里针对于需求、开发、测试、文档、运维几个维度,进行了整合,同时也制定和管理方案,以达到基础规范 – 组织结构 – 基础架构 – 业务开发 – 持续集成– 自动化部署 – 自动化测试 – 生产运维监控 – 在线升级 几个方向自动化,这里不得不提一下Jenkins+git,确实是整个自动化的核心。目前考虑了一下这些工具,针对于开发的: 序号 说明 技术 版本 备注 " B# E' i3 m6 \
1代码管理Git(gitee)2.17.1企业内部建议使用gitlab(更能满足需求)& W% O1 \5 l% k) i! U8 L. u3 z
5代码管理客户端SourceTree2.7.6
7 {/ @* u. [# S7 L4 w \7 T2自动部署工具Jenkins2.107.1不建议使用太新版本
& B, {; D4 k5 }7 Q2 ?3 ^) b3私服库Nexus2.14.1不建议使用3.x版本 a& _ a7 {* Z0 ^) ^9 B
3构建工具Maven3.6.0 % X; c( ]6 O/ n4 g( r' T$ b
4代码检测Sonar5.x不建议使用太新版本
: R! @8 z/ L6 ~+ Z! p, n5镜像管理Harbor1.5.2 $ y! O3 h t7 Z
6镜像容器Docker1.12.1 8 I) K2 {; ]* _3 _1 G* ^
7容器管理Kubernetes1.10不建议使用太高版本,跟着社区走0 ]* ~) _" r1 Q/ s1 A
自动化持续集成的效果如下: ![]()
文档持续集成效果如下: ![]()
3、下载和整理软件工具,整理软件工具版本 基础环境完善及配置,为整个开发平台做基础,以环境搭建为主,为本地开发环境。 使用的阿里云服务器规划如下: 序号 作用 服务器资源(系统/内存/硬盘) IP规划 备注
* b( W2 @9 d. t4 B& M6 B( V1开发服务器_masterCentOS7.4_x64_4G_40G192.168.1.110 / K x6 D8 l4 @: D1 f) m
2开发服务器_slaveCentOS7.4_x64_2G_40G192.168.1.111
0 \; I, F5 d, h, V3 T3开发服务器_slaveCentOS7.4_x64_1G_40G192.168.1.112 . {5 @: h8 x: Z5 w; d8 p3 w
规划的使用工具如下: 序号 说明 工具 IP 是否集群 文档完善进度 备注 0 U* P$ L( r% h5 C1 h
1基础环境JDK172.18.11.17单点已完善
& j- @+ F0 p, n7 G8反向代理Nginx172.18.11.17单点已完善
! {: w; i( x! K/ I+ z6 D11自动部署工具Jenkins172.18.11.17单点完善中 & a$ s3 Z4 \) Q
12私服库Nexus172.18.11.17单点已完善 4 Z: ~! g: }4 i4 [; a3 ]- F1 y
17链接跟踪skywalking172.18.11.17单点 - a& F3 A. v! B. Q
13代码检测Sonar172.18.11.17单点 , \: C3 h r; G
2缓存工具Redis172.18.11.17单点已完善 : p; @. `1 m0 H/ V7 U+ t
4消息列表Kafka172.18.11.17单点已完善 7 I/ U3 Q5 \! Q3 c. b) T3 z
10分布式注册中心zeekeeper172.18.11.17单点完善中
; I' U' k) c# y3 }" M) q6分布式注册中心Eurake172.18.11.139单点 # A# ?" L, P) Q6 x9 }3 |
10分页式配置中心Apollo172.18.11.139单点 R2 I. V# b9 o
6数据库MySQL172.18.11.139单点已完善 b# T1 W& g- j# O
1开发过程管理Jira192.168.1.120集群
( x5 X- Z& F2 _8 O8 L" ?3Redis监控工具Redmon192.168.1.119单点 9 Y0 T5 {+ J9 o8 C2 r3 [
5消息管理工具Kafka-Manager192.168.1.119单点
; @" Y4 ~" J/ Q$ J% F( {7数据库主从MyCAT192.168.1.111/112集群
+ }6 i* ?0 T* \) o* L& K7容器管理Kubernetes192.168.1.1110/111/112集群 - s+ p& r6 A r
9高可用KeepAlived192.168.1.110/111/112集群 , W: T: a5 \8 g. m
14镜像管理Harbor192.168.1.110单点 , I; c* y6 S6 ], K3 ?5 Z
15自动部署Ansible192.168.1.119单点
6 O, [. b. ~4 S s; g. O, @16自动部署管理Ansible Tower192.168.1.119单点
, f; Z! m! {) L( l( l17链接跟踪pinpoint192.168.1.119单点 7 L# H# u2 i, n( t) a) U2 ~1 i
18日志监控elk192.168.1.119集群
" }& ]. m- O) R. Y0 |& R19服务器监控Zabbix192.168.1.119单点 ! k# H, X, H0 I$ a" s$ _
; s1 s% x. Y" x q' ~ Q4、规划平台非功能性需求组件,包括基础组件等 功能重用,组件重用,目前最好的技术承载就是微服务了,这也是这几年才出现,这样规划研发平台构架,对我而言,微服务架构自然成为不二的选择(后面的中台业务也是在微服务上进行进程创建) 服务设计原则 服务单库设计,以减少迁移,服务之前影响等;
. p5 q @2 ^4 E9 V基础服务只为调用设计,位于服务的底层或者中间层,基础服务禁止调用业务服务;+ ^$ L, J% [; {+ z* J
业务服务调用基础服务,或者其它服务,业务服务为服务的顶层,用于定制化业务;
" y$ C. w2 x9 A) k& M: i同一级服务之间可以互相调用,只能自下往下调用,平级调用,禁止自下往上调用,以避免服务混乱及维护混乱。1 t. ~' i; U$ c3 W. O
每种服务目录按999个服务规划 服务设计规划 类型 目录名称 说明 备注
. w. j. {' g I5 M5 I教程示例服务做示例工程,包含有所有服务调用示例
6 _: j7 O& U9 N1 p0 k( P前端应用门户服务与中台服务同级,用于统一门户服务 ; J" ~/ v9 a7 O9 D7 f1 C' @
前端应用应用服务前端应用或者手机应用
, p' F+ ~4 |: }- N) T- ?网关应用网关服务对外网关服务,与平台组件同级,但仅做为网关部分
, u' J: F9 D+ ?: K( D: Q中台服务中台服务服务于前端应用,处理业务,可以服务之间互相调用,或者调用基础服务 ) \- U# z4 H, t5 i6 C
基础服务基础服务公用基础组件,只能被调用或者调用公共或者组件包,不能主动调用其它服务 ; t5 p4 `: Q* r8 P- L
基础服务公共服务基础公共包,所有工程的基础,包括配置,页面,核心包等
7 A, C8 D# J7 B* R基础服务组件服务基础组件包,用于第三方等,组件包不能单独运行,只能被依赖 7 P3 ?" U3 l6 K* j% {. X: c
运维环境监控服务监控平台,用于运维平台,目前仅规划,有可能与平台服务合并一起 9 h/ S- d x# e% |; F
运维环境平台服务包括注册中心,配置中心等
/ b, l2 y7 Q( x5 `& J% p工程目录规划 关于命名方向,一直不知道用什么名字比较合适,所以使用自己网站的域名。 序号 目录名称 目录规划 端口规划 权限 备注 $ K$ `. y+ C% N2 ^4 y
1公共服务alinesno-cloud-common 研发 / S% j. l9 E3 X
2组件服务alinesno-cloud-component 研发 9 K+ W/ x- g8 r k8 ]
3平台服务alinesno-cloud-platform24000+研发 % a) W6 G( `6 e0 `3 L4 u/ Y, i6 g
4基础服务alinesno-cloud-base25000+研发
; K& h' O6 i. F4 a6 `5业务服务alinesno-cloud-business26000+开发 : [( D; U% O2 u
6门户服务alinesno-cloud-portal27000+研发 7 f: i3 S" I9 Y+ `: \+ U
7网关服务alinesno-cloud-gate28000+开发
+ t# M2 k0 u7 H- z' g* `+ ~8应用服务alinesno-cloud-web34000+开发
0 j/ ?6 H, o4 v! `9监控服务alinesno-cloud-monitor35000+研发 ) j) f" H9 W: s" f/ u2 x
10示例服务alinesno-cloud-demo30000+研发置于guide基线
4 @7 b% @% |! R1 `/ R" X1 d3 l }5、提取出业务中台规划,并完善组件,打磨中台业务产品 上面也提到,业务中台也是在微服务上面构建,设计原则加上了几个点,分别如下: 按“重中台”+”轻应用”设计,业务应用逻辑思路放在前端应用,推荐是尽量减少或不拆分前端服务;# G) a) [9 t% ~0 d: M# y# p" ^! A* Q
重中台的建设,在于前端应用共性部分的抽取和后期的沉淀,形成中台业务服务;
8 \! n: B1 k1 D- {$ u中台服务调用基础服务,或者其它同级服务,中台服务为服务的中层,用于业务共性(共享)抽取; 整体中台的业务架构如下: ![]()
中台业务架构设计 中台业务建设目标如下 ![]()
中台业务建设目标 6、统一和通用的权限配置系统和界面设计 这个就是通用的,只需要在配置平台添加好菜单,分配好账号权限,本地开发只需要账户就可以进行本地开发,配置平台包括的一些功能规划如下: 应用管理:用于配置系统应用,添加和删除管理。
0 H" V8 X9 s$ \4 y' n% ?用户管理:用户是系统操作者,该功能主要完成系统用户配置。, ~8 Z- G& B% Z2 O M
部门管理:配置系统组织机构(公司、部门、小组),树结构展现支持数据权限。
( Z0 B* z7 y8 |8 ^岗位管理:配置系统用户所属担任职务。
8 V( j% O4 e2 t& y% u菜单管理:配置系统菜单,操作权限,按钮权限标识等。" B# |+ ]. a- [$ X
角色管理:角色菜单权限分配、设置角色按机构进行数据范围权限划分。
) u, Q' k) t( r字典管理:对系统中经常使用的一些较为固定的数据进行维护。/ q$ i4 L i( ^1 h- N7 U
参数管理:对系统动态配置常用参数。+ s I6 L8 _: { g
通知公告:系统通知公告信息发布维护。
: [( @/ A [, n" D& M; }操作日志:系统正常操作日志记录和查询;系统异常信息日志记录和查询。
# [! K/ V! }" B9 G3 z* r p+ i登录日志:系统登录日志记录查询包含登录异常。0 Y1 Z8 c6 V: _7 F' g; P
在线用户:当前系统中活跃用户状态监控。
6 p; H+ R; s8 a( ` D+ g定时任务:在线(添加、修改、删除)任务调度包含执行结果日志。+ a- b0 }: e, X: J
代码生成:前后端代码的生成(java、html、xml、sql)支持CRUD下载 。 然后大概的设计如下: ![]()
开发人员的开发流程如下: ![]()
7、完善软件组件辅助,包括测试、运维、环境管理 以上组件的搭建过程,如果一个人管理,会产生很多问题,同时延伸出其它方向的建设,其中包括最基础的服务器管理和服务预警方向,安全策略管理,平台整体入口和常用文档,功能,平台组件的质量保证,即运维、机房环境,测试这几块。在建设统一研发平台的同时,也自然包括建设这些内容,大概做了一些建设工作,以下为一些设计的示例。 机房服务器管理系统 ![]()
机房管理系统,针对云系统和服务部署的管理 平台统一门户管理 - : r) {' |0 y# }/ g4 h7 R" |1 ^; O
% j6 x9 F* q- t5 F/ f. }
其它的建议,如包括人才培养,大数据,人工智能,项目管理,都是在研发平台中慢慢积累和培养的产物,而最终的结果是为了整理出一套完整的企业统一研发平台。 四、总结以上为目前搭建整体个人整体研发平台的思路和设计,一个优秀的研发人员的工作并非只是编制代码,更多的是自己能做什么,完成什么,有什么价值,能帮别人做什么。
4 D2 y. E$ X8 v n |