.Net微服務實戰之DevOps篇

技術只是基礎

　　該系列的兩篇文章《.Net微服務實戰之技術選型篇》和《.Net微服務實戰之技術架構分層篇》都是以技術角度出發描述微服務架構的實施。

　　若是技術選型篇敘述的是工具，那麼架構分層篇講的就是技巧，而本篇要討論的就是原則。一直以來我會給身邊向我探討問題的人灌輸一種理念，沒有什麼技術銀彈，由於咱們作的是軟件工程，提供的是問題相應的解決方案，不一樣類型問題的解決方案是存在着本質上的差別。

　　繼續提供以前的源碼：https://github.com/SkyChenSky/Sikiro

PS：該篇文章與.Net無關，其實主要是沿用前面兩篇文章的命名，此外我認爲DevOps不是簡單的工具使用，應從軟件工程角度進行出發。

什麼纔是優秀的架構設計？

　　曾經有好幾個同行問過我同一個問題：什麼纔是優秀的架構設計？我一直信奉着兩句話和一個定律：

• 架構服務於業務，技術服務於架構 
• 康威定律（簡單理解成組織架構的設計等同於系統架構的設計）

　　架構設計其實就是一種方案的取捨，在有限的資源裏(包括但不限人力、時間)能讓團隊順利的實施技術，同時知足業務規模的須要，我認爲能夠稱之爲優秀的架構設計，簡單來講兩個字合適

 

架構核心要素

　　核心的主要5大：性能、可用性、伸縮性、擴展性、安全性。 

　　而咱們所討論的微服務，選擇了擴展性，犧牲了可用性、性能，擴展性的目的就是爲了快速響應需求變化、下降系統耦合度、提升系統模塊的複用度。而微服務的調用是經過跨進程的網絡通訊的，跟進程內方法調用比無疑是慢了一個單位；本來單服務99.99%高可用，假如如今三個服務就是99.99%*99.99%*99.99%=99.97%。

　　固然咱們能夠在基於微服務的經過引入其餘技術提升可用性、伸縮性和安全，可是確保無疑是犧牲了性能，除了性能還會在團隊開發效率與運維複雜度上會受到影響。因而可知，沒有萬能技術手段，而架構其實在取捨。

　　引入一種技術一定帶新的技術問題這是個必然結果，剛提到團隊開發效率與運維複雜度會受到影響，那是否有辦法緩解甚至解決並提升呢？既然涉及到團隊、流程這些關鍵字那麼就應該向軟件工程方向尋找方案，合適架構實施還須要合適的開發模式進行支撐的，而風靡全球的DevOps就是不二之選。

軟件工程

 　　在行業盛傳的一條公式：軟件 = 軟件工程 + 程序，可想而知軟件工程的佔據多麼重要的比重。那麼什麼是軟件工程？百度是這麼解釋的：

　　軟件工程是研究和應用如何以系統性的、規範化的、可定量的過程化方法去開發和維護軟件，以及如何把通過時間考驗而證實正確的管理技術和當前可以獲得的最好的技術方法結合起來的學科。它涉及到程序設計語言、數據庫、軟件開發工具、系統平臺、標準、設計模式等方面。

　　我本身從新總結了一個軟件工程的通俗描述，經過多人協做、有目標、有步驟、有計劃的並使用科學方法論指導開發與維護程序的這個過程。也能夠用一條公式表達：軟件工程 = 工具 + 流程 + 模式。

　

軟件危機

　　軟件工程的出現目的是爲了解決軟件危機的。軟件危機實際上是當時落後的軟件生產方式沒法知足迅速增加的計算機軟件需求，從而致使軟件開發與維護過程當中出現一列的嚴重問題的現象。那麼三次軟件危機是什麼呢？我整理了個表格（詳細能夠自行百度閱讀）

名稱	時間	緣由	解決方案
第一次軟件危機	20世紀60年代—70年代	使用機器語言或者彙編語言在特定的機器上進行軟件的設計與編寫，引出的「抽象性」和「可移植性」的問題	高級的編程語言+瀑布開發模式
第二次軟件危機	20世紀80年代—90年代	軟件複雜性進一步升級，須要更好更好的「可組合性」(Composability)、「可延展性」(Malleability)以及「可維護性」(Maintainability)	面向對象編程語言+設計模式
第三次軟件危機	2005年至今	軟件的發展速度已經遠超於硬件的發展，體現於需求複雜度、技術複雜度、團隊協做	更好的工具、開發模式、與協做流程

 

 　　由上可見，軟件的快速發展直接促使了軟件工程上的進步，新的工具、新的開發與設計模式，新的協做流程也隨之而生。

開發模式的發展

　　我工做多年經歷了多家公司，所經歷的有三種開發模式，瀑布、敏捷、DevOps。那麼這三種主流的開發模式也對應着三個發展階段：

瀑布開發模式

　　瀑布開發模式是在第一次軟件危機1970時Winston Royce博士提出來。其思想是把項目過程劃分爲主要的六個階段：需求收集、需求分析、軟件設計、程序編碼、軟件測試、運行維護。團隊劃分也經過崗位職責進行劃分：產品團隊、開發團隊、測試團隊、運維團隊。到目前爲止該開發模式仍然用到作項目制的開發團隊。

　　那麼其優勢與劣勢也很明顯，優勢是計劃明確，職責清晰，循序漸進的完成就好。缺點是週期容易拖得太長，不容易調整變動，每一個人只爲本身職責範圍內的負責，跨部門溝通成本大（這就是爲何我在圖裏畫了兩堵牆的緣由）。我本身呆過一個瀑布模式的團隊，在項目立項後就會被項目經理調動資源成爲團隊，而開發人員只會在這一次批次負責編碼與修改測試反饋的問題，基本上上線後的問題跟你無關（除非緊急嚴重的），其餘的BUG也許是下一個批次的另一個開發人員幫你填。

 敏捷開發模式

　　準確的說敏捷開發是一種價值觀和原則的體現，2001年17位IT大佬想把瀑布發模式這種重量級的開發過程替換成一種更加輕量級，惋惜你們都沒有達成統一意見所以把各自都認同的觀念整理出來成爲敏捷宣言。

　　敏捷開發其實把產品、開發、測試三種崗位職責的人緊密的聯繫了起來，由原來長週期的大目標拆解成了一個個短週期的小目標。他之因此快，不是由於寫代碼快了，而是節省了不少沒必要要的前置條件與返工，同時小步快跑的交付也能夠提升團隊的士氣，一個長週期項目那枯燥、乏味、痛苦的過程，誰試誰知道。

　　舉個例子，你們都是爲公司的同個產品努力，沒有什麼合同談判可言，只要需求要求相互瞭解清楚而且可行就能夠開幹了。寫詳細設計文檔的時間，還不如花時間多溝通下需求的核心點，想辦法設計得更容易知足需求。短週期的交付後，產品與客戶就能夠及時的查看交付效果並相應的優化與調整。（快速響應並不表明隨時隨地接受變動響應，能夠統一歸到下一個迭代週期，我不贊同拍拍腦殼的變動，本身都沒清楚的功能怎麼說服客戶使用？）

　　

　　敏捷開發的最大好處之一就是短週期的持續交付，這樣方式能在現階段的互聯網行業獲得更快速的響應與市場的搶佔，同時能很好的進行技術改進與試錯。可是這種」野蠻的「方式會讓開發團隊與運維團隊造成一條鴻溝，而鴻溝的造成主要緣由是運維團隊但願軟件的運做是可靠的，因此他們對資源的變更、新技術的使用尤其的當心、謹慎。

　　我曾經呆過一個敏捷開發團隊，生產出了問題運維團隊會自行去修改配置，固然會越改越錯了，並且一天發佈次數多了，就會起爭執。

DevOps

　　DevOps能夠看過是敏捷的擴展與延申，它的出現就是爲了解決開發團隊與運維團隊的那條鴻溝，只要存在人工處理的方式擔憂的問題總會出現，同一段程序不管執行多少次相同輸入的輸出老是一致的，可是人的處理卻不能保證，那麼使用自動化改善協做的過程，鴻溝天然就跨越了，。那麼開發團隊與運維團隊就能夠爲相同的目標與方向而努力。而組織架構也將演變成以下：

　　

　　從上圖也與開頭的康威定律作了一個很好的呼應。

 我是如何實施DevOps的？

　

技術

　　這個角度是你們最樂意去關注的，在咱們團隊主要使用瞭如下技術，腳本什麼的我就不花時間貼出來了，在我看來工具的使用，只要花點時間就能解決。

類型	名稱
持續集成/持續交付	Jenkins
源代碼管理	Gitlab
雲平臺	阿里雲
軟件包管理器	私有Nuget
代碼檢查	Reshaper
容器化	Docker
分佈式鏈路跟蹤	SkyWalking
日誌系統	ES+Filebeat+kibana
系統監控	Prometheus

　　本來代碼檢查想引入SonarQube代替人工檢查+Reshaper，惋惜於服務器資源不足。

　　對於通常的團隊，我建議優先從Gitlab+Jenkins搭建好完成CI/CD，其次把日誌系統給完善起來，這二者完成得越早，給團隊帶來的收益就越高，後續纔會有更多的時間來完善整套技術體系，這是一個良性的循環。

人

　　人延申出的就是團隊與文化，通過上面的講解你們都意識到軟件工程就是同樣多人協做的工做，只有團隊目標一致，共同負責承擔團隊的項目，願意一同與項目成長才能很好的實施DevOps。就像多匹馬拉車同樣，只有它們都有共同的目標的時候才能快速拉車到目的，若是他們一匹向東一匹西，只會讓馬車沒法前行甚至四分五裂。

　　在個人團隊，由於在招聘人員的時候已經進行過了篩選，因此在合做上很是的順利，固然我也常常在例會和業餘的時候都會給你們傳達思想，讓團隊成員真正的從實際意義上去理解如今的作法。

　　對於已經成型的團隊來講如何去落地呢？無非三種，激勵、考覈和逐步試行。若是有條件的公司能夠設置獎金激勵，若是有績效考覈的能夠將DevOps實施歸入考覈目標，若是二者都沒的，那就選取團隊裏願意改變的同事進行試行，使用事後都說好的那麼更會有說服力。　

流程　

 　　爲了落實了文化的改進與技術的使用的這個過程，咱們須要科學的、有步驟、有計劃的方式完成這項工做，而且可讓這套標準化的方式能夠重複使用到其餘項目上。

　　在個人團隊是有產品、前端開發，後端開發、測試、運維組成的。我採用了原型模式+DevOps模式：

• 　　產品人員會優先使用Axure RP工具把需求整理產出原型並與需求方確認。
• 　　產品確認好的原型就是咱們技術的輸入，技術拿到需求後會作一次需求評審，主要是排查需求疑惑和確認需求目標。
• 　　需求明確後，由我使用Visual Project任務拆解與排期，任務會創建在咱們的項目管理系統Redmine上，若是任務週期過程，我會拆分紅多個可交付的短週期，通常會控制在2個星期內。
• 　　接到任務後，你們就跟根據本身的任務使用PowerDesigner數據庫設計（早期是由我獨裁設計，後期團隊發展壯大了，就由業務負責人各自設計），在這個階段，若是有新的服務與新的工具庫須要部署，我就會正面與運維溝通讓他把自動化給完成。
• 　　由於咱們是先後端分離的，因此咱們使用了Swagger減小了寫接口文檔的時間，全部任務是否完成之前端是否對接好接口爲主導，前端對接好後，就會在Redmine修改本身的任務狀態並新建一個測試任務給到測試。
• 　　測試會根據本身寫好的測試用例，進行對完成的任務進行場景測試，若是有BUG會在Redmine提給相應的人進行修改。通常會先由前端人員排查是不是他的交互上的BUG，若是確認是數據問題那麼就會轉給後端開發，開發人員定位BUG時，能夠經過咱們的SkyWalking和Kibana聯合定位問題，定位問題時間通常都在2-10分鐘。
• 　　代碼合併到測試分支後就會經過Jenkins發佈到測試環境，生產環境的發佈是合併到生產環境後手動確認發佈的。

　　除此以外，每週一會有一個例會內容不限工做，也能夠分享週末去哪裏娛樂了。在該迭代週期快到結束的2-3天會開一個進度會議，看看你們完成狀況。由於公司沒有下午茶，因此咱們本身經過玩搶紅包領到最大的兩個的請吃下午茶，最少一星期一次。

 結束

　　該篇到這裏就分享結束了，也是該系列的最後一篇，我曾經認爲技術與管理必須二選一，自從我成爲了一個技術與團隊的負責人後，終於讓我認識到，一個優秀的技術思想仍是須要一些管理手段才能很好的實施，而咱們的技術管理無非就是軟件工程。