開發爲何要從零開始搭建屬於本身的統一研發平臺和中臺架構

從零開始搭建的意思，就是從需求分析，系統規劃，設計分析和落地實踐幾個步驟，從無到有的過程。考慮左右，爲了我的學習和提高，選型基於流行的springboot+springcloud，從零開始搭建一套本身用於學習的研發平臺。

總體平臺的流程，從管理、開發、測試、運維、生產幾條線，實現總體平臺的落地和管理，下面是總體研發平臺架構。

整個研發平臺架構設計

整個研發平臺產物：https://gitee.com/landonniao

總體研發平臺使用的基線規劃以下

平臺全部基線及全部項目目錄結構，總體從零開始進行平臺基線搭建及規劃，多個基線的規劃，考慮更合適多個崗位角色的管理

序號	基線說明	基線地址	維護人員	狀態	備註
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			略

1、我的爲何要搭建一個統一研發平臺

一、爲了有方向感，不迷茫，不浪費時間，有可行的學習計劃

上大學的時候，就開始學習計算機，從基礎的Java到Java web，再到框架，再到在學校接一些小項目，如企業網站，兼職網，報名網站等，這幾步路大概走了2年左右，而在學完兩年以後，人仍是很迷茫，方向感還不是特別強，而在找方向和突破迷茫上面，走過了不少彎路，終於找到點方向。後來才發現，不少這個專業的同窗，可能畢業幾年以後，依然還找不到方向和定位，東學一點西學一點，很浪費時間，可能醒悟的時候，已通過了3~5年，很難再轉回頭。

二、爲了在工做和學習過得中不斷積累和提升學習效率

學習和工做的幾年裏，幾乎每一個項目，資料，文檔，規範都是有共性的，而因爲各個項目的不統一，在接收新項目的，幾乎都從零開始，一些非功能性需求的建設已經佔去了實際項目的不少時間，投入需求建設的時間其實沒多少，最簡單的，代碼的CURD都是同樣，本身在作的時候，針對每一個項目都有改進，好比這個項目統一了CURD，那個項目梳理出了公共代碼，可是項目是分開的，最終新的項目，也是從零開始或者複製，再加上人工，手工，人肉運維，不斷的繁瑣而簡單的工做的學習中沒法脫身，影響進入下一步學習。這相似於溫水煮青蛙，沒有感受，可能慢慢拖死本身，特別是作項目的前兩年，除了數據的添加刪除，仍是這些。重複開發，沒法共用這些都消耗了很長的時間。好比一直想學大數據，可是因爲沒有好的平臺依託，目前仍是沒法投入學習。

三、爲了能夠總結和反思，能夠不斷的打磨出一個平臺，一個產品或者一個精品

這幾年的工做和學習中，有不少都是在學習，在努力，也很上進，資料有不可勝數，可是卻在用的時候，沒有深刻或者精通某一個模塊，最多見的，連本身精通的模塊都沒法界定，不自信，沒有本身的深刻心得，比較浮在表面上。本身近乎有兩年的狀態如此，一直在努力，可是卻一直沒有達到預期的，別人承認的效果，接觸的面好像不少，可是卻沒有哪同樣是徹底吃透的。最終發現的緣由是沒有作好總結和複習，反思，一個知識點覺得看過了就懂，可是沒有結合實際進行提煉與打磨，沒有吃透，就往下一個模塊，最終致使好像不斷的在撿東西，但最終這些東西都不是本身的。因此須要打磨本身的東西，能談出本身心得，這就是本身的產品，就是本身的精品，或者本身就一個精品。

四、爲了擴大本身的視野和學習心態，開放心態

學習中最怕和就是無溝通與交流，沒有他人的指點和本身的固步自封，坐井觀天等心態，在學得一些技術以後，開始自覺得自，而後偏向於安逸。明顯，這種心態本身曾經有過，並且持續很長一段時間。這間接形成無論是溝通、技術方面都慢慢出現問題。本身一直相信，心態有多開放，有多寬容，幫助的人越多，本身也才更好的成長，無論是技術仍是管理，包括生活等。

2、我的須要搭建怎麼樣的研發平臺來學習

一、能夠隨時隨地的學習，只要有網絡和電腦，就能夠學習

閒碎的時間經常存在，好比學校上機，看手機，還有一些無聊的聚會，甚至上廁所，這些都要能能夠用來學習，網絡如今無處不在，有個手機就能夠上網，因此這些時間要能充分利用起來。

二、能夠好的工具和學習環境

學習過程，工具的成熟度和熟練程度不少時間影響到本身的學習效率。好比vim的配置使用，熟練以後，無論在編輯和代碼方面，速度都比通常的操做快得多。還有jenkins，在這個工具上不斷的學習和積累，無論是配置和權限，發佈，運維，分佈式都能很大的幫助，同時節省不少時間。

三、能夠不斷的學習目標，最好從基礎程序員到總監

學習有一個從零開始，到不斷往上的過程，而且有目標，知道每一個目標階段須要什麼樣的技術，能力，成長時間等，作到心知肚明，不浪費多餘時間 。能夠不斷的有學習積累，在積累上由量變到質變

五、能夠不斷的跟外界溝通交流，避免閉門造車，固步自封

須要不斷的與外部學習，獲取到外部的建議，看到本身的不足，同時也看到本身的優勢。在本身不斷學習的過程當中，同時不斷的成果，並讓別人看到，給本身提建議，在本身把本身的思路成果對外貢獻的同時，別人也同樣幫本身提高。

3、研發平臺怎麼搭建，搭建到什麼樣的程度

搭建的思路都是先有一稿，而後再後期慢慢在這一稿上面作好優化，同時參考當前社會主流技術，便於學習。

一、制定總體學習規劃和學習路線，技術路線和成長規劃

平臺構建過程當中，產生大量的技術產物和管理產物，而在大量的項目過程當中，同時也會產生大量的問題致使過程當中細節的不完善，人爲的不完善及限制，致使平臺沒法正常管理和運維，開發平臺的管理規劃即針對總體平臺的運維管理進行的建議，以達到管理統一有序，過程明確，產物明確，目標明確等

從需求->準備->組織->開發<->內部測試<->用戶測試<->自動測試->生產(試運行)->生產->運維整個流程完善，每一個流程中又包括多個工做，如需求管理，同時每一個工具必然有必定的產物，如需求管理的產物是需求管理基線和需求文檔。

序號	模塊	功能	產物	備註
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	生產(正式)	日誌管理

爲達到以上的要求，也爲了過程有記錄和沉澱，考慮一些必要性的管理工具，暫時考慮如下幾個工具：

序號	說明	技術	版本	備註
1	文檔管理	GitBook		企業內部作好考慮，團隊未必每一個人都能接受markdown
2	Wiki管理	GitBook		企業內部作好考慮，團隊未必每一個人都能接受markdown
3	開發過程管理	Jira
4	開發工具管理	百度網盤		公司內部建議使用FTP或者內部文件系統
5	郵件通知	163郵箱		建議使用企業內部郵箱

如下爲文檔管理基線示例

二、制定持續集成環境，爲學習提供基礎的準備和提高效率

持續集成他一套比較成熟的自動化研發解決方案，使用也有幾年時間，不一樣的人有不一樣的設計，有些可能只是發佈工程，這裏針對於需求、開發、測試、文檔、運維幾個維度，進行了整合，同時也制定和管理方案，以達到基礎規範 – 組織結構 – 基礎架構 – 業務開發 – 持續集成– 自動化部署 – 自動化測試 – 生產運維監控 – 在線升級 幾個方向自動化，這裏不得不提一下Jenkins+git，確實是整個自動化的核心。目前考慮了一下這些工具，針對於開發的：

序號	說明	技術	版本	備註
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	不建議使用過高版本,跟着社區走

自動化持續集成的效果以下：

文檔持續集成效果以下:

三、下載和整理軟件工具，整理軟件工具版本

基礎環境完善及配置，爲整個開發平臺作基礎，以環境搭建爲主,爲本地開發環境。

使用的阿里雲服務器規劃以下：

序號	做用	服務器資源(系統/內存/硬盤)	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

規劃的使用工具以下：

序號	說明	工具	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	單點

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

四、規劃平臺非功能性需求組件，包括基礎組件等

功能重用，組件重用，目前最好的技術承載就是微服務了，這也是這幾年纔出現，這樣規劃研發平臺構架，對我而言，微服務架構天然成爲不二的選擇（後面的中臺業務也是在微服務上進行進程建立）

服務設計原則

服務單庫設計,以減小遷移，服務以前影響等；
基礎服務只爲調用設計，位於服務的底層或者中間層，基礎服務禁止調用業務服務；
業務服務調用基礎服務，或者其它服務，業務服務爲服務的頂層，用於定製化業務；
同一級服務之間能夠互相調用，只能自下往下調用，平級調用，禁止自下往上調用，以免服務混亂及維護混亂。
每種服務目錄按999個服務規劃

服務設計規劃

類型	目錄名稱	說明	備註
教程	示例服務	作示例工程，包含有全部服務調用示例
前端應用	門戶服務	與中臺服務同級，用於統一門戶服務
前端應用	應用服務	前端應用或者手機應用
網關應用	網關服務	對外網關服務,與平臺組件同級，但僅作爲網關部分
中臺服務	中臺服務	服務於前端應用，處理業務，能夠服務之間互相調用，或者調用基礎服務
基礎服務	基礎服務	公用基礎組件，只能被調用或者調用公共或者組件包,不能主動調用其它服務
基礎服務	公共服務	基礎公共包,全部工程的基礎，包括配置，頁面，核心包等
基礎服務	組件服務	基礎組件包，用於第三方等，組件包不能單獨運行，只能被依賴
運維環境	監控服務	監控平臺，用於運維平臺，目前僅規劃,有可能與平臺服務合併一塊兒
運維環境	平臺服務	包括註冊中心，配置中心等

工程目錄規劃

關於命名方向，一直不知道用什麼名字比較合適，因此使用本身網站的域名。

序號	目錄名稱	目錄規劃	端口規劃	權限	備註
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基線

五、提取出業務中臺規劃，並完善組件，打磨中臺業務產品

上面也提到，業務中臺也是在微服務上面構建，設計原則加上了幾個點，分別以下：

按「重中臺」+」輕應用」設計，業務應用邏輯思路放在前端應用，推薦是儘可能減小或不拆分前端服務;
重中臺的建設，在於前端應用共性部分的抽取和後期的沉澱，造成中臺業務服務;
中臺服務調用基礎服務，或者其它同級服務，中臺服務爲服務的中層，用於業務共性(共享)抽取；

總體中臺的業務架構以下：

中臺業務架構設計

中臺業務建設目標以下

中臺業務建設目標

六、統一和通用的權限配置系統和界面設計

這個就是通用的，只須要在配置平臺添加好菜單，分配好帳號權限，本地開發只須要帳戶就能夠進行本地開發，配置平臺包括的一些功能規劃以下：

應用管理：用於配置系統應用，添加和刪除管理。
用戶管理：用戶是系統操做者，該功能主要完成系統用戶配置。
部門管理：配置系統組織機構（公司、部門、小組），樹結構展示支持數據權限。
崗位管理：配置系統用戶所屬擔任職務。
菜單管理：配置系統菜單，操做權限，按鈕權限標識等。
角色管理：角色菜單權限分配、設置角色按機構進行數據範圍權限劃分。
字典管理：對系統中常用的一些較爲固定的數據進行維護。
參數管理：對系統動態配置經常使用參數。
通知公告：系統通知公告信息發佈維護。
操做日誌：系統正常操做日誌記錄和查詢；系統異常信息日誌記錄和查詢。
登陸日誌：系統登陸日誌記錄查詢包含登陸異常。
在線用戶：當前系統中活躍用戶狀態監控。
定時任務：在線（添加、修改、刪除)任務調度包含執行結果日誌。
代碼生成：先後端代碼的生成（java、html、xml、sql)支持CRUD下載 。

而後大概的設計以下：

開發人員的開發流程以下：

七、完善軟件組件輔助，包括測試、運維、環境管理

以上組件的搭建過程，若是一我的管理，會產生不少問題，同時延伸出其它方向的建設，其中包括最基礎的服務器管理和服務預警方向，安全策略管理，平臺總體入口和經常使用文檔，功能，平臺組件的質量保證，即運維、機房環境，測試這幾塊。在建設統一研發平臺的同時，也天然包括建設這些內容，大概作了一些建設工做，如下爲一些設計的示例。

機房服務器管理系統

機房管理系統，針對雲系統和服務部署的管理

平臺統一門戶管理

• 

其它的建議，如包括人才培養，大數據，人工智能，項目管理，都是在研發平臺中慢慢積累和培養的產物，而最終的結果是爲了整理出一套完整的企業統一研發平臺。

4、總結

以上爲目前搭建總體我的總體研發平臺的思路和設計，一個優秀的研發人員的工做並不是只是編制代碼，更多的是本身能作什麼，完成什麼，有什麼價值，能幫別人作什麼。