技術(shù)只是基礎(chǔ)

　　該系列的兩篇文章《.Net微服務(wù)實(shí)戰(zhàn)之技術(shù)選型篇》和《.Net微服務(wù)實(shí)戰(zhàn)之技術(shù)架構(gòu)分層篇》都是以技術(shù)角度出發(fā)描述微服務(wù)架構(gòu)的實(shí)施。

　　如果技術(shù)選型篇敘述的是工具，那么架構(gòu)分層篇講的就是技巧，而本篇要討論的就是原則。一直以來(lái)我會(huì)給身邊向我探討問(wèn)題的人灌輸一種理念，沒(méi)有什么技術(shù)銀彈，因?yàn)槲覀冏龅氖擒浖こ?#xff0c;提供的是問(wèn)題相應(yīng)的解決方案，不同類型問(wèn)題的解決方案是存在著本質(zhì)上的差異。

　　繼續(xù)提供之前的源碼：https://github.com/SkyChenSky/Sikiro

PS：該篇文章與.Net無(wú)關(guān)，其實(shí)主要是沿用前面兩篇文章的命名，此外我認(rèn)為DevOps不是簡(jiǎn)單的工具使用，應(yīng)從軟件工程角度進(jìn)行出發(fā)。

什么才是優(yōu)秀的架構(gòu)設(shè)計(jì)？

　　曾經(jīng)有好幾個(gè)同行問(wèn)過(guò)我同一個(gè)問(wèn)題：什么才是優(yōu)秀的架構(gòu)設(shè)計(jì)？我一直信奉著兩句話和一個(gè)定律：

• 架構(gòu)服務(wù)于業(yè)務(wù)，技術(shù)服務(wù)于架構(gòu)?

• 康威定律（簡(jiǎn)單理解成組織架構(gòu)的設(shè)計(jì)等同于系統(tǒng)架構(gòu)的設(shè)計(jì)）

　　架構(gòu)設(shè)計(jì)其實(shí)就是一種方案的取舍，在有限的資源里(包括但不限人力、時(shí)間)能讓團(tuán)隊(duì)順利的實(shí)施技術(shù)，同時(shí)滿足業(yè)務(wù)規(guī)模的需要，我認(rèn)為可以稱之為優(yōu)秀的架構(gòu)設(shè)計(jì)，簡(jiǎn)單來(lái)說(shuō)兩個(gè)字合適

?

架構(gòu)核心要素

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

　　而我們所討論的微服務(wù)，選擇了擴(kuò)展性，犧牲了可用性、性能，擴(kuò)展性的目的就是為了快速響應(yīng)需求變化、降低系統(tǒng)耦合度、提高系統(tǒng)模塊的復(fù)用度。而微服務(wù)的調(diào)用是通過(guò)跨進(jìn)程的網(wǎng)絡(luò)通信的，跟進(jìn)程內(nèi)方法調(diào)用比無(wú)疑是慢了一個(gè)單位；原本單服務(wù)99.99%高可用，假如現(xiàn)在三個(gè)服務(wù)就是99.99%*99.99%*99.99%=99.97%。

　　當(dāng)然我們可以在基于微服務(wù)的通過(guò)引入其他技術(shù)提高可用性、伸縮性和安全，但是確保無(wú)疑是犧牲了性能，除了性能還會(huì)在團(tuán)隊(duì)開(kāi)發(fā)效率與運(yùn)維復(fù)雜度上會(huì)受到影響。由此可見(jiàn)，沒(méi)有萬(wàn)能技術(shù)手段，而架構(gòu)其實(shí)在取舍。

　　引入一種技術(shù)必定帶新的技術(shù)問(wèn)題這是個(gè)必然結(jié)果，剛提到團(tuán)隊(duì)開(kāi)發(fā)效率與運(yùn)維復(fù)雜度會(huì)受到影響，那是否有辦法緩解甚至解決并提高呢？既然涉及到團(tuán)隊(duì)、流程這些關(guān)鍵字那么就應(yīng)該向軟件工程方向?qū)ふ曳桨?#xff0c;合適架構(gòu)實(shí)施還需要合適的開(kāi)發(fā)模式進(jìn)行支撐的，而風(fēng)靡全球的DevOps就是不二之選。

軟件工程

?　　在行業(yè)盛傳的一條公式：軟件 = 軟件工程 + 程序，可想而知軟件工程的占據(jù)多么重要的比重。那么什么是軟件工程？百度是這么解釋的：

　　軟件工程是研究和應(yīng)用如何以系統(tǒng)性的、規(guī)范化的、可定量的過(guò)程化方法去開(kāi)發(fā)和維護(hù)軟件，以及如何把經(jīng)過(guò)時(shí)間考驗(yàn)而證明正確的管理技術(shù)和當(dāng)前能夠得到的最好的技術(shù)方法結(jié)合起來(lái)的學(xué)科。它涉及到程序設(shè)計(jì)語(yǔ)言、數(shù)據(jù)庫(kù)、軟件開(kāi)發(fā)工具、系統(tǒng)平臺(tái)、標(biāo)準(zhǔn)、設(shè)計(jì)模式等方面。

　　我自己重新總結(jié)了一個(gè)軟件工程的通俗描述，通過(guò)多人協(xié)作、有目標(biāo)、有步驟、有計(jì)劃的并使用科學(xué)方法論指導(dǎo)開(kāi)發(fā)與維護(hù)程序的這個(gè)過(guò)程。也可以用一條公式表達(dá)：軟件工程 = 工具 + 流程 + 模式。

　

軟件危機(jī)

　　軟件工程的出現(xiàn)目的是為了解決軟件危機(jī)的。軟件危機(jī)其實(shí)是當(dāng)時(shí)落后的軟件生產(chǎn)方式無(wú)法滿足迅速增長(zhǎng)的計(jì)算機(jī)軟件需求，從而導(dǎo)致軟件開(kāi)發(fā)與維護(hù)過(guò)程中出現(xiàn)一列的嚴(yán)重問(wèn)題的現(xiàn)象。那么三次軟件危機(jī)是什么呢？我整理了個(gè)表格（詳細(xì)可以自行百度閱讀）

名稱	時(shí)間	原因	解決方案
第一次軟件危機(jī)	20世紀(jì)60年代—70年代	使用機(jī)器語(yǔ)言或者匯編語(yǔ)言在特定的機(jī)器上進(jìn)行軟件的設(shè)計(jì)與編寫，引出的“抽象性”和“可移植性”的問(wèn)題	高級(jí)的編程語(yǔ)言+瀑布開(kāi)發(fā)模式
第二次軟件危機(jī)	20世紀(jì)80年代—90年代	軟件復(fù)雜性進(jìn)一步升級(jí)，需要更好更好的“可組合性”(Composability)、“可延展性”(Malleability)以及“可維護(hù)性”(Maintainability)	面向?qū)ο缶幊陶Z(yǔ)言+設(shè)計(jì)模式
第三次軟件危機(jī)	2005年至今	軟件的發(fā)展速度已經(jīng)遠(yuǎn)超于硬件的發(fā)展，體現(xiàn)于需求復(fù)雜度、技術(shù)復(fù)雜度、團(tuán)隊(duì)協(xié)作	更好的工具、開(kāi)發(fā)模式、與協(xié)作流程

?

?　　由上可見(jiàn)，軟件的快速發(fā)展直接促使了軟件工程上的進(jìn)步，新的工具、新的開(kāi)發(fā)與設(shè)計(jì)模式，新的協(xié)作流程也隨之而生。

開(kāi)發(fā)模式的發(fā)展

　　我工作多年經(jīng)歷了多家公司，所經(jīng)歷的有三種開(kāi)發(fā)模式，瀑布、敏捷、DevOps。那么這三種主流的開(kāi)發(fā)模式也對(duì)應(yīng)著三個(gè)發(fā)展階段：

瀑布開(kāi)發(fā)模式

　　瀑布開(kāi)發(fā)模式是在第一次軟件危機(jī)1970時(shí)Winston Royce博士提出來(lái)。其思想是把項(xiàng)目過(guò)程劃分為主要的六個(gè)階段：需求收集、需求分析、軟件設(shè)計(jì)、程序編碼、軟件測(cè)試、運(yùn)行維護(hù)。團(tuán)隊(duì)劃分也通過(guò)崗位職責(zé)進(jìn)行劃分：產(chǎn)品團(tuán)隊(duì)、開(kāi)發(fā)團(tuán)隊(duì)、測(cè)試團(tuán)隊(duì)、運(yùn)維團(tuán)隊(duì)。到目前為止該開(kāi)發(fā)模式仍然用到做項(xiàng)目制的開(kāi)發(fā)團(tuán)隊(duì)。

　　那么其優(yōu)點(diǎn)與劣勢(shì)也很明顯，優(yōu)點(diǎn)是計(jì)劃明確，職責(zé)清晰，按部就班的完成就好。缺點(diǎn)是周期容易拖得太長(zhǎng)，不容易調(diào)整變更，每個(gè)人只為自己職責(zé)范圍內(nèi)的負(fù)責(zé)，跨部門溝通成本大（這就是為什么我在圖里畫了兩堵墻的原因）。我自己呆過(guò)一個(gè)瀑布模式的團(tuán)隊(duì)，在項(xiàng)目立項(xiàng)后就會(huì)被項(xiàng)目經(jīng)理調(diào)動(dòng)資源成為團(tuán)隊(duì)，而開(kāi)發(fā)人員只會(huì)在這一次批次負(fù)責(zé)編碼與修改測(cè)試反饋的問(wèn)題，基本上上線后的問(wèn)題跟你無(wú)關(guān)（除非緊急嚴(yán)重的），其他的BUG也許是下一個(gè)批次的另外一個(gè)開(kāi)發(fā)人員幫你填。

?敏捷開(kāi)發(fā)模式

　　準(zhǔn)確的說(shuō)敏捷開(kāi)發(fā)是一種價(jià)值觀和原則的體現(xiàn)，2001年17位IT大佬想把瀑布發(fā)模式這種重量級(jí)的開(kāi)發(fā)過(guò)程替換成一種更加輕量級(jí)，可惜大家都沒(méi)有達(dá)成統(tǒng)一意見(jiàn)因此把各自都認(rèn)同的觀念整理出來(lái)成為敏捷宣言。

　　敏捷開(kāi)發(fā)其實(shí)把產(chǎn)品、開(kāi)發(fā)、測(cè)試三種崗位職責(zé)的人緊密的聯(lián)系了起來(lái)，由原來(lái)長(zhǎng)周期的大目標(biāo)拆解成了一個(gè)個(gè)短周期的小目標(biāo)。他之所以快，不是因?yàn)閷懘a快了，而是節(jié)省了很多不必要的前置條件與返工，同時(shí)小步快跑的交付也可以提高團(tuán)隊(duì)的士氣，一個(gè)長(zhǎng)周期項(xiàng)目那枯燥、乏味、痛苦的過(guò)程，誰(shuí)試誰(shuí)知道。

　　舉個(gè)例子，大家都是為公司的同個(gè)產(chǎn)品努力，沒(méi)有什么合同談判可言，只要需求要求相互了解清楚并且可行就可以開(kāi)干了。寫詳細(xì)設(shè)計(jì)文檔的時(shí)間，還不如花時(shí)間多溝通下需求的核心點(diǎn)，想辦法設(shè)計(jì)得更容易滿足需求。短周期的交付后，產(chǎn)品與客戶就可以及時(shí)的查看交付效果并相應(yīng)的優(yōu)化與調(diào)整。（快速響應(yīng)并不代表隨時(shí)隨地接受變更響應(yīng)，可以統(tǒng)一歸到下一個(gè)迭代周期，我不贊同拍拍腦袋的變更，自己都沒(méi)清楚的功能怎么說(shuō)服客戶使用？）

　　

　　敏捷開(kāi)發(fā)的最大好處之一就是短周期的持續(xù)交付，這樣方式能在現(xiàn)階段的互聯(lián)網(wǎng)行業(yè)得到更快速的響應(yīng)與市場(chǎng)的搶占，同時(shí)能很好的進(jìn)行技術(shù)改進(jìn)與試錯(cuò)。但是這種”野蠻的“方式會(huì)讓開(kāi)發(fā)團(tuán)隊(duì)與運(yùn)維團(tuán)隊(duì)形成一條鴻溝，而鴻溝的形成主要原因是運(yùn)維團(tuán)隊(duì)希望軟件的運(yùn)作是可靠的，所以他們對(duì)資源的變動(dòng)、新技術(shù)的使用尤為的小心、謹(jǐn)慎。

　　我曾經(jīng)呆過(guò)一個(gè)敏捷開(kāi)發(fā)團(tuán)隊(duì)，生產(chǎn)出了問(wèn)題運(yùn)維團(tuán)隊(duì)會(huì)自行去修改配置，當(dāng)然會(huì)越改越錯(cuò)了，而且一天發(fā)布次數(shù)多了，就會(huì)起爭(zhēng)執(zhí)。

DevOps

　　DevOps可以看過(guò)是敏捷的擴(kuò)展與延申，它的出現(xiàn)就是為了解決開(kāi)發(fā)團(tuán)隊(duì)與運(yùn)維團(tuán)隊(duì)的那條鴻溝，只要存在人工處理的方式擔(dān)心的問(wèn)題總會(huì)出現(xiàn)，同一段程序無(wú)論執(zhí)行多少次相同輸入的輸出總是一致的，但是人的處理卻不能保證，那么使用自動(dòng)化改善協(xié)作的過(guò)程，鴻溝自然就跨越了，。那么開(kāi)發(fā)團(tuán)隊(duì)與運(yùn)維團(tuán)隊(duì)就可以為相同的目標(biāo)與方向而努力。而組織架構(gòu)也將演變成如下：

　　

　　從上圖也與開(kāi)頭的康威定律做了一個(gè)很好的呼應(yīng)。

?我是如何實(shí)施DevOps的？

　

技術(shù)

　　這個(gè)角度是大家最樂(lè)意去關(guān)注的，在我們團(tuán)隊(duì)主要使用了以下技術(shù)，腳本什么的我就不花時(shí)間貼出來(lái)了，在我看來(lái)工具的使用，只要花點(diǎn)時(shí)間就能解決。

類型	名稱
持續(xù)集成/持續(xù)交付	Jenkins
源代碼管理	Gitlab
云平臺(tái)	阿里云
軟件包管理器	私有Nuget
代碼檢查	Reshaper
容器化	Docker
分布式鏈路跟蹤	SkyWalking
日志系統(tǒng)	ES+Filebeat+kibana
系統(tǒng)監(jiān)控	Prometheus

　　原本代碼檢查想引入SonarQube代替人工檢查+Reshaper，可惜于服務(wù)器資源不足。

　　對(duì)于一般的團(tuán)隊(duì)，我建議優(yōu)先從Gitlab+Jenkins搭建好完成CI/CD，其次把日志系統(tǒng)給完善起來(lái)，這兩者完成得越早，給團(tuán)隊(duì)帶來(lái)的收益就越高，后續(xù)才會(huì)有更多的時(shí)間來(lái)完善整套技術(shù)體系，這是一個(gè)良性的循環(huán)。

人

　　人延申出的就是團(tuán)隊(duì)與文化，經(jīng)過(guò)上面的講解大家都意識(shí)到軟件工程就是一樣多人協(xié)作的工作，只有團(tuán)隊(duì)目標(biāo)一致，共同負(fù)責(zé)承擔(dān)團(tuán)隊(duì)的項(xiàng)目，愿意一同與項(xiàng)目成長(zhǎng)才能很好的實(shí)施DevOps。就像多匹馬拉車一樣，只有它們都有共同的目標(biāo)的時(shí)候才能快速拉車到目的，如果他們一匹向東一匹西，只會(huì)讓馬車無(wú)法前行甚至四分五裂。

　　在我的團(tuán)隊(duì)，因?yàn)樵谡衅溉藛T的時(shí)候已經(jīng)進(jìn)行過(guò)了篩選，所以在合作上非常的順利，當(dāng)然我也經(jīng)常在例會(huì)和業(yè)余的時(shí)候都會(huì)給大家傳達(dá)思想，讓團(tuán)隊(duì)成員真正的從實(shí)際意義上去理解現(xiàn)在的做法。

　　對(duì)于已經(jīng)成型的團(tuán)隊(duì)來(lái)說(shuō)如何去落地呢？無(wú)非三種，激勵(lì)、考核和逐步試行。如果有條件的公司可以設(shè)置獎(jiǎng)金激勵(lì)，如果有績(jī)效考核的可以將DevOps實(shí)施納入考核目標(biāo)，如果兩者都沒(méi)的，那就選取團(tuán)隊(duì)里愿意改變的同事進(jìn)行試行，使用過(guò)后都說(shuō)好的那么更會(huì)有說(shuō)服力。　

流程　

?　　為了落實(shí)了文化的改進(jìn)與技術(shù)的使用的這個(gè)過(guò)程，我們需要科學(xué)的、有步驟、有計(jì)劃的方式完成這項(xiàng)工作，并且可以讓這套標(biāo)準(zhǔn)化的方式可以重復(fù)使用到其他項(xiàng)目上。

　　在我的團(tuán)隊(duì)是有產(chǎn)品、前端開(kāi)發(fā)，后端開(kāi)發(fā)、測(cè)試、運(yùn)維組成的。我采用了原型模式+DevOps模式：

• 　　產(chǎn)品人員會(huì)優(yōu)先使用Axure RP工具把需求整理產(chǎn)出原型并與需求方確認(rèn)。

• 　　產(chǎn)品確認(rèn)好的原型就是我們技術(shù)的輸入，技術(shù)拿到需求后會(huì)做一次需求評(píng)審，主要是排查需求疑惑和確認(rèn)需求目標(biāo)。

• 　　需求明確后，由我使用Visual Project任務(wù)拆解與排期，任務(wù)會(huì)建立在我們的項(xiàng)目管理系統(tǒng)Redmine上，如果任務(wù)周期過(guò)程，我會(huì)拆分成多個(gè)可交付的短周期，一般會(huì)控制在2個(gè)星期內(nèi)。

• 　　接到任務(wù)后，大家就跟根據(jù)自己的任務(wù)使用PowerDesigner數(shù)據(jù)庫(kù)設(shè)計(jì)（早期是由我獨(dú)裁設(shè)計(jì)，后期團(tuán)隊(duì)發(fā)展壯大了，就由業(yè)務(wù)負(fù)責(zé)人各自設(shè)計(jì)），在這個(gè)階段，如果有新的服務(wù)與新的工具庫(kù)需要部署，我就會(huì)正面與運(yùn)維溝通讓他把自動(dòng)化給完成。

• 　　因?yàn)槲覀兪乔昂蠖朔蛛x的，所以我們使用了Swagger減少了寫接口文檔的時(shí)間，所有任務(wù)是否完成以前端是否對(duì)接好接口為主導(dǎo)，前端對(duì)接好后，就會(huì)在Redmine修改自己的任務(wù)狀態(tài)并新建一個(gè)測(cè)試任務(wù)給到測(cè)試。

• 　　測(cè)試會(huì)根據(jù)自己寫好的測(cè)試用例，進(jìn)行對(duì)完成的任務(wù)進(jìn)行場(chǎng)景測(cè)試，如果有BUG會(huì)在Redmine提給相應(yīng)的人進(jìn)行修改。一般會(huì)先由前端人員排查是否是他的交互上的BUG，如果確認(rèn)是數(shù)據(jù)問(wèn)題那么就會(huì)轉(zhuǎn)給后端開(kāi)發(fā)，開(kāi)發(fā)人員定位BUG時(shí)，可以通過(guò)我們的SkyWalking和Kibana聯(lián)合定位問(wèn)題，定位問(wèn)題時(shí)間一般都在2-10分鐘。

• 　　代碼合并到測(cè)試分支后就會(huì)通過(guò)Jenkins發(fā)布到測(cè)試環(huán)境，生產(chǎn)環(huán)境的發(fā)布是合并到生產(chǎn)環(huán)境后手動(dòng)確認(rèn)發(fā)布的。

　　除此之外，每周一會(huì)有一個(gè)例會(huì)內(nèi)容不限工作，也可以分享周末去哪里娛樂(lè)了。在該迭代周期快到結(jié)束的2-3天會(huì)開(kāi)一個(gè)進(jìn)度會(huì)議，看看大家完成情況。因?yàn)楣緵](méi)有下午茶，所以我們自己通過(guò)玩搶紅包領(lǐng)到最大的兩個(gè)的請(qǐng)吃下午茶，最少一星期一次。

?結(jié)束

　　該篇到這里就分享結(jié)束了，也是該系列的最后一篇，我曾經(jīng)認(rèn)為技術(shù)與管理必須二選一，自從我成為了一個(gè)技術(shù)與團(tuán)隊(duì)的負(fù)責(zé)人后，終于讓我認(rèn)識(shí)到，一個(gè)優(yōu)秀的技術(shù)思想還是需要一些管理手段才能很好的實(shí)施，而我們的技術(shù)管理無(wú)非就是軟件工程。

總結(jié)

以上是生活随笔為你收集整理的.Net微服务实战之DevOps篇的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。