寫這篇文章為了更清楚自己技術能力，同時分享給大夥，看看自己技術水平位於哪裡。
個人能力有限，基於我所理解的知識來講解一下：從程式設計師到大型分散式架構師，我們自己到底位於哪裡。
描述不當之處還請各路大佬點明，老弟也好更上一層樓！！！
本人就以之前畫的微服務系統架構圖來逐一講解。
上一篇講述了：Java程式設計師刻苦修煉 鍛造基礎
這一篇接著講述……
1.分散式服務治理方案
1.1.簡述幾個名詞
什麼是服務治理？
反過來讀一下：治理服務。分散式服務治理方案就是通過什麼方案來治理分散式的服務。強調的還是“服務”，所以治理的前提是有錯綜複雜的業務服務，才需要整這麼一套方案去解決這問題。
分散式架構是什麼？
一整套的分散式架構的搭建就像建造一個自動化生產車間。新增的“業務系統N”部署到這個大家庭便會擁有架構中一整套的能力（服務治理能力、自動化能力、大資料能力等等)。
應用上雲和分散式架構
在這幾年經常會聽到或談到“上雲”這個詞語，“應用上雲”和“分散式架構”這兩者乍眼一看兩者沒啥關係，其實關係大得很。就以阿里云為例：你將新增的“業務系統N”部署到阿里雲，需要什麼能力的服務是不是用錢買就行啦？或者直接搞個“行業解決方案”。這種第三方雲又稱為公有云；有“公”就有“私”，私有云就是企業自個獨有的雲；兩者一混就變成了混合雲。雲可以看作是完整的一套分散式架構+基礎設施。怎麼上雲，先申請資源（軟體資源、硬體資源和網路資源），再將業務服務部署到這分散式架構中，從而實現所有資源可插拔和服務的統一管理，這就是為什麼現在都喜歡搞“上雲”的原因之一。
本文是為讀者做定位和後續學習有目標，在此不展開太多。
1.2.技術實現方案
常用的兩種分散式服務治理方案：RESTful 和 RPC 分散式服務治理方案。
兩者最本質的區別：
RESTful 強調一切都看作資源，對資源進行操作；
RPC 是遠端過程呼叫，強調的是客戶端和服務端的互動。
RESTful分散式服務治理技術方案
技術實現方案：SpringCloud
RPC分散式服務治理技術方案
技術實現方案：Dubbo + Zookeeper
兩種方案中都沒有提供一套完整的服務治理技術實現，還需加入鏈路追蹤技術、監控告警系統、日誌分析系統等。
鏈路追蹤系統
在分散式環境中一個業務處理涉及多個服務間的呼叫，傳統方式通過系統日誌很難做到故障問題快速定位，而通過鏈路追蹤可以實現故障快速定位。鏈路追蹤系統除了故障快速定位功能，還有視覺化（如效能指標）、依賴優化（梳理服務依賴關係以及優化）、資料分析（如使用者的行為路徑，彙總分析應用在很多業務場景）。
監控告警系統
一般監控有流量監控、異常監控、資源使用率、請求延遲等。當監控的資料超過指定範圍，就會通過郵件或電話進行告警通知，也可以在視覺化平臺檢視監控資料，收到告警通知的人員便會去處理相應問題。
日誌分析系統
日誌分析是運維工程師解決系統故障，發現問題的主要手段。
服務治理技術包含在紅色框中
2.DevOps(開發運維一體化)
為了高可用，將業務服務叢集化是一件很正常的事，但每次都要改動都要部署到不同的幾臺伺服器，做著重複的工作而且很有可能出錯，一次改動一天部署完成算是很順利的事了。是不是很想要有自動化部署這種東西呢？其實自動化在很多行業早就有了，現在很多行業都已邁入智慧化時代了。
DevOps開發運維一體化並不是讓開發去做運維，而是使開發和運維通過一些機制有機結合、高效統一，成為一個整體，從而消除開發團隊和運維團隊之間的隔閡，有效提升應用服務的研發和運維運營效率。
關鍵技術
-
kubernetes（自動化運維平臺）-- 平臺
-
Jenkins Pipeline（流水線） -- 流水線
-
docker（容器） -- 包裹
主要涉及兩種角色：開發人員（developer）和 運維人員（Operation）
&
兩者的隔閡其實是通過容器化部署方式來解決，運維人員只需要知道容器映象怎麼部署即可，不需要知道其中的細節。
持續整合（CI）：從程式設計師提交程式碼到自動打包生成docker映象，並部署到指定測試環境
持續交付和部署（CD）：測試通過後，運維人員將docker映象部署到生成環境
整個流程都可以在k8s平臺中看到，並且支援專案部署的回滾操作，更多細節就不一一展開。
3.大資料接入
經常會聽到大資料“殺熟”，同一個平臺殺熟就算了，跨各大平臺殺熟就很讓人惱火。比如：我在淘寶或京東搜尋了下運動器材，然後在各種平臺都會收到各式各樣的運動器材推薦。這種智慧推送又被稱為智障推送，比如：我看了某種商品的某種規格後，再次搜尋商品就都是這種規格，其實這不是我想要的結果。大資料是把雙刃劍，搞得好智慧，搞不好智障，甚至觸犯法律條款。
分點簡述
-
大資料平臺：Hadoop
-
資料來源：資料庫，快取中介軟體，檔案儲存，資料倉儲等等。
-
資料採集方式：實時採集 和 離線採集
-
資料採集技術：kafka，flume，sqoop 等等，不同的資料來源使用不同的採集中介軟體技術
-
資料儲存技術：Hbase，HDFS 等等
-
資料處理方式：實時處理 和 離線批量處理，分別對應不同的技術棧
-
資料服務：提供服務實現價值，如：精準營銷，瀏覽，分析檢索，下載等等
-
平臺管理技術：Apache Ambari（供應、管理、監控等）和Zookeeper（平臺配置與排程）
4.其他
4.1.內網DNS
優點：方便記憶和服務遷移IP更換隻需要修改DNS即可；
缺點：DNS服務可能成為效能瓶頸和影響可用性。
4.2.網路區域和出入網控制
業務服務都部署在內網環境，主要原因是安全問題和IP資源問題。
內網環境還可以拆分成多個區域：DMZ區、業務區。DMZ 稱為隔離區，對外對內都有防火牆隔離，隔離外網和內網的一個區域。常用於部署以外網對接的系統服務。內網業務區，顧名思義是部署業務相關的服務。
統一入網：服務部署在內網環境，每個對外提供服務的系統都需要有個入口，為了網路安全和更好管理便有了統一入網，需要提供網際網路服務的系統申請入網資源即可。
統一出網：對於內網系統需要訪問網際網路資源時，則通過統一出網來控制。
4.3.安全技術
網路安全
-
內網部署，內網專有網路
-
統一出入網
-
應用防火牆WAF：免受各種常見攻擊（XSS 攻擊、注入攻擊、DDOS攻擊等）
-
使用HTTPS
-
運維人員必須通過內網堡壘機來訪問內網伺服器
等等
編碼安全
-
瀏覽器Cookie 加密與過期
-
服務間通訊加密
-
登入防爆力影像驗證碼等的多種驗證方式（如：郵件或簡訊驗證碼的一次一密）
-
資料防爬蟲機器人驗證
-
重要資訊資料脫敏（如：手機號，姓名，證件號，卡號等）
等等
伺服器安全
-
通過滲透測試確認資料庫、應用等安全性，常用的技術：nmap、burp suite、sqlmap等。
-
容器部署的安全性
-
常用中介軟體安全性
等等多種安全技術，從程式碼到整個平臺所涉及之處都要考慮安全問題。
4.6.其他嘮嗑
隨著業務的發展，會持續出現技術問題，業務問題，開發問題，運維問題，業務響應速度等等。避免重複造輪子，需要對通用能力抽離；不同業務不斷髮展形成不同的軟體平臺，平臺間職能邊界劃分問題和資料孤島問題，需要引入領域驅動設計思想和中臺思想來解決相應問題，但專案一開始還是建議使用物件導向軟體設計方法，不要看到到處說DDD就湊熱鬧，領域驅動設計在2014年都出書了也不是什麼新鮮事物，過度設計還不如層次分明更利於開發維護。
閱讀上一篇：從程式設計師到大型分散式架構師，自己到底位於哪裡（一）
轉載指明出處！！！