歡迎光臨
每天分享高質量文章

微服務與持續集成:拆之前要先解決合的問題

一、持續集成對於微服務的意義:拆之前要先解決合的問題

在很多微服務化的文章中,很少會把持續集成放在第一篇,因為大多數的文章都會講如何拆的問題,例如拆的粒度,拆的時機,拆的方式。
為什麼需要拆呢?因為這是人類處理問題的本質方式:將一個大的複雜問題,變成很多個小問題解決。
所以當一個系統複雜到一定程度,當維護一個系統的人數多到一定程度,解決問題的難度和溝通成本大大提高,因而需要拆成很多個工程,拆成很多個團隊,分而治之。
然而當每個子團隊將子問題解決了,整個系統的問題就解決了麽?你可以想象你將一輛整車拆成零件,然後再組裝起來的過程,你就可以想象拆雖然不容易,合則更難,需要各種標準,各種流水線,才能將零件組裝稱為車。
我們先來回顧一下拆的過程。
最初的應用大多數是一個單體應用。

一個Java後端,後面跟一個資料庫,基本上就搞定了。
隨著系統複雜度的增加,首先Java程式需要做的是縱向的拆分。

首先最外面是一個負載均衡,接著是接入的Nginx,做不同服務的路由。
不同的服務拆成獨立的行程,獨立部署,每個服務使用自己的資料庫和快取,解決資料庫和快取的單點瓶頸。
資料庫使用一主多從的樣式,進行讀寫分離,主要針對讀多寫少的場景。
為了承載更多的請求,設置快取層,將資料快取到Memcached或者Redis中,增加命中率。
當然還有些跨服務的查詢,或者非結構化資料的查詢,引入搜索引擎,比關係型資料庫的查詢速度快很多。

在高併發情況下,僅僅縱向拆分還不夠,因而需要做真正的服務化。
一個服務化的架構如圖所示。
首先是接入層,這一層主要實現API網關和動態資源和靜態資源的分離及快取,並且可以在這一層做整個系統的限流。
接下來是Web層,也就是controller,提供最外層的API,是對外提供服務的一層。
下麵是組合服務層,有時候被稱為編排層,Compose層,是實現複雜邏輯的一層。
下麵是基礎服務層,是提供原子性的基本的邏輯的一層,他下麵是快取,資料庫。
服務之間需要治理,需要相互發現,所以一般會有Dubbo或者Spring Cloud一樣的框架。
對所有的服務,都應該有監控告警,及時發現異常,並自動修複或者告警運維手動修複。
對於所有的服務的日誌,應該有相同的格式,收集到一起,稱為日誌中心,方便發現錯誤的時候,在統一的一個地方可以debug。
對於所有的服務的配置,有統一的管理的地方,稱為配置中心,可以通過修改配置中心,下發配置,對於整個集群進行配置的修改,例如打開熔斷或者降級開關等。
通過簡單的描述,大家可以發現,從一個簡單的單體應用,變成如此複雜的微服務架構,除了關心怎麼拆的問題,還必須關註:
  • 如何控制拆的風險

  • 如何保證代碼質量

  • 如何保證功能不變,不引入新的Bug

答案當然就是集成,從一開始就集成,並且不斷的集成,反覆的將拆分的模塊重新組合,看看是否能夠順利組合起來,並且保證功能的不變。
要是不沒事兒就組合一下,天知道幾個月以後還能不能合的起來。
別忘了程式是人寫的,你和你媳婦長時間不溝通都對不上默契,別說兩個程式員了。


二、持續集成就是不斷的嘗試在一起

集成就是在一起。

為什麼需要一個統一的代碼倉庫Git來做代碼管理呢?是為了代碼集成在一起。
為什麼需要進行構建build呢?就是代碼邏輯需要集成在一起,編譯不出錯。
為什麼要單元測試呢?一個模塊的功能集成在一起能夠正確工作。
為什麼需要聯調測試Staging環境呢?需要將不同模塊之間集成在一起,在一個類生產的環境中進行測試。
最終才是部署到生產環境中,將所有人分開做的工作才算真正的合在了一起。

持續集成就是制定一系列流程,或者一個系列規則,將需要在一起的各個層次規範起來,方便大家在一起,強迫大家在一起。


三、持續集成、持續交付、持續部署、敏捷開發、DevOps都啥關係?

這些概念都容易混淆,他們之間是什麼關係呢?

敏捷開發Agile是一種開發流程,是一種快速迭代的開發流程,每個開發流程非常短,長到一個月,短到兩個星期,就會是一個周期,在這個周期中,每天都要開會同步,每天都要集成。正是因為周期短,才需要持續的做這件事情,如果一個開發周期長達幾個月,則不需要持續的集成,最後留幾個星期的集成時間一起做也是可以的,但是這樣就不能達到互聯網公司的快速迭代,也是我們常常看到傳統公司的做法。
持續集成往往指對代碼的提交,構建,測試的過程,也就是上述的在一起的過程。
持續交付是指將集成好的交付物,例如war、jar或者容器鏡像,部署在聯調環境,或者預發環境的過程。
持續部署是指將交付物持續部署在生產環境的過程。
我們常說CI/CD,CD有時候指的是Delivery交付,有的是指Deployment部署,對於非生產環境,自動部署是沒有問題的,對於生產環境,往往還是需要有專人來進行更為嚴肅的部署過程,不會完全的自動化。
接下來就是DevOps,DevOps不只是CI/CD,除了技術和流程,還包含文化。例如容器化帶來的一個巨大的轉變是,原來只有運維關心環境的部署,無論是測試環境,還是生產環境,都是運維搞定的,而容器化之後,需要開發自己寫Dockerfile,自己關心環境的部署。因為微服務之後,模塊太多了,讓少數的運維能夠很好的管理所有的服務,壓力大,易出錯,然而開發往往分成很多的團隊,每個模塊自己關心自己的部署,則不易出錯,這就需要運維一部分的工作讓研發來做,需要研發和運維的打通,如果公司沒有這個文化,研發的老大說我們不寫Dockerfile,則DevOps是搞不定的。


四、從一個持續集成的日常,看上述的幾個概念如何實踐

這是一個持續集成的流程,但是運行起來更加的複雜。
首先,專案開發的流程使用的是Agile,用常見的scrum為例子。

每天早上第一件事情,就是開站會standup meeting,為什麼要站著呢?因為時間不能太長,微服務的一個模塊,大概需要5-9人的團隊規模,如果團隊規模太大了,說明服務應該進行拆分了,這個團隊規模,是能夠保證比較短的時間之內過完昨天的狀態的。
一定要大家一起開,而不要線下去更新Jira,雖然看起來一樣,但是執行起來完全不一樣。只有大家一起開,一起看燃盡圖,一起說我昨天做了什麼,今天打算做什麼,有什麼阻礙,才能夠讓大家都瞭解情況,不要期望大家會去看別人的Jira,經驗告訴你,不會的。
而且這個站會對於開發是比較大的壓力,例如你的一個功能block了依賴方的開發,在會議上會暴露出來,大家都知道這件事情了,一天block,兩天block,第三天你都不好意思去說了,這會強迫你將大任務,比如原來寫1周乾一件什麼事情,寫成小時級別,這樣每天你都有的說,昨天完成了一個task,而不是周只在那裡說乾同樣一件事情,而且一旦有了block,team lead會知道這件事情,會幫你趕緊解決這個事情,推進整個專案的進展。讓一個技術人員在團隊面前承認這件事情我嘗試了幾天,的確搞不定了,也是一種壓力。
站會中的內容其實在前一天晚上就要開始準備了。
持續集成要求每天都提交代碼,這樣才能降低代碼集成的風險,不能埋頭寫一周一起提交,這樣往往集成不成功。怎麼樣才能鼓勵每天都提交代碼呢?一個就是第二天的站會,你這個功能代碼提交了,單元測試通過了,第二天才能說做完了,否則不算,這就逼得你,將大任務拆成小任務,每天都多次提交。
而且Git的提交方式,是後提交者有責任去merge,保證代碼的編譯通過和測試通過,你會發現,如果你不及時提交,等你改了一大片代碼,別人都提交完了,這一大片的衝突都是你來merge,測試用例不通過的你來fix,所以逼的你有一個小的功能的改動,就儘早提交,pull一下發現沒有人提交,趕緊提交。
提交不是馬上進入主庫,而是需要代碼審核,這是把控代碼質量的重要的環節。
代碼質量的控制往往每個公司都有文件,甚至你可以從網上下載一篇很長很長的Java代碼規範。但是我們常常看到的例子是,規範是有,但是虱子多了不咬人,規範太多的,誰也記不住,等於沒有規範。
所以建議將複雜的規範通過專案組內部的討論,簡化為簡單的10幾條軍規,深入人心,大家都容易記住,並且容器執行。
代碼審核往往需要註意下麵的幾方面:
  • 代碼結構:整個專案組應該規定統一的代碼組織結構,使得每個開發拿到另一個人的代碼,都能看的熟悉的面孔。這也是Scrum中提倡的每個開發之間是可替代的,當一個模塊有了阻礙,其他人是可以幫上忙的。至於核心的邏輯,估計審核人員也來不及細看,這不要緊,核心邏輯是否通過,不能靠眼睛,要靠測試。

  • 有沒有註釋,尤其是對外的接口,應該有完善的註釋,方便自動生成接口文件。

  • 異常的處理,是否丟擲太過寬泛的異常,是否吞掉異常,是否吞掉異常的日誌等。

  • 對於pom是否有修改,引入了新的jar。

  • 對於配置檔案是否有修改,對外訪問是否設置超時。

  • 對於資料庫是否有修改,是否經過DBA審核。

  • 接口實現是否冪等,因為Dubbo和Spring Cloud都會重試接口。接口是否會升級,是否帶版本號。

  • 是否有單元測試。

當然還有一些不容易一眼看出來的,可以通過一段時間通過統一的代碼review,來修改這些問題。
  • 某個類代碼長度過長

  • 設計是否合理,高內聚低耦合

  • 資料庫設計是否合理

  • 資料庫事務是否使用合理

  • 代碼是否有明顯的阻塞

代碼審核完畢之後提交上去之後,一個是要通過靜態代碼審查,可以發現一些可能帶來代碼風險的問題,例如異常過於寬泛等。
在就是要通過單元測試。我們應該要求每個類都要有單元測試,並且單元測試改寫率要達到一定的指標。單元測試要有帶Mock的模塊內的集成測試。
在編譯過程中會觸發單元測試,單元測試不通過,已經代碼改寫率,都會統計後發郵件,抄送所有的人,這對於研發來講又是一個壓力。
當有一天你的提交break掉了測試,或者代碼改寫率很低,則就像通報批評一樣,你需要趕緊去修改。
單元測試完畢之後,就會上傳成果物,或者是war或者是jar,一般會用nexus,因為有版本號,有md5,可以保證安裝在環境中的就是某個版本的某個包,我們還遇到過有使用FTP的,這樣一個是很難保證版本號的維護,升級和回滾比較難弄,另一個是沒有md5,很可能包不完整都有可能的,而且一旦發生,很難發現。
如果使用了容器,則還需要編譯Dockerfile,使用Docker鏡像作為交付,能夠實現更好的環境一致性,保證原子的升級和回滾。
每天下班前,當天的代碼需要提交到庫中去,晚上會做一次統一的環境部署和集成測試。
每天晚上凌晨,會有自動化的腳本將Docker鏡像通過編排部署一個完整的環境,然後跑集成測試用例,集成測試用例應該是基於API的,很多的公司是基於UI的,這樣由於UI變化太快,還有UI不能改寫所有的場景,所以還是建議UI和API分離,通過API進行集成測試,有了每天的測試,才能保證每天晚上的版本都是可以交付的版本,也保證我們微服務拆分的時候,儘管改了很多,不會因為新的修改,破壞掉原來能夠通過的測試用例,保證不會有了新的,壞了舊的。
這個集成測試或者叫回歸測試每天晚上都做,都是在一個全新的環境中,這就是持續部署和持續交付。
如果某一天測試不通過,則會發出郵件來,是因為當天誰的哪個提交,導致測試不通過,抄送所有人,這是另一個壓力。
所以第二天的站會上,昨天你完成了哪些功能,是否提交了,是否完成了單元測試,是否通過了集成測試,就都知道了,你需要給大家一個解釋,然後進入到新一天的開發。
到了兩周,一個周期完畢,可以上線到生產環境了,可以通知有權限的運維進行操作,但是也是通過自動化的腳本進行部署的。
這就是整個過程,層層保證質量,從中可以看到,敏捷開發,持續集成,持續交付,持續部署,DevOps是互相聯繫的,少了哪個,流程都玩不轉。


五、有關代碼結構

代碼結構往往包括:
  • API接口包

  • 訪問外部服務包

  • 資料庫DTO

  • 訪問資料庫包

  • 服務與商務邏輯

  • 外部服務

如果使用Dubbo RPC,則API接口往往在一個單獨的jar裡面,被服務端和客戶端共同依賴,但是使用了Spring Cloud的restful方式就不用了,只要在各自的代碼裡面定義就可以了,會變成json的方式傳遞,這樣的好處是當jar有多個版本依賴,需要升級的時候,關係非常複雜,難以維護,而json的方式比較好的解決了這個問題。
這個模塊提供了哪些接口,只要到API接口這個package下麵找就可以了。因為無論是Dubbo還是Spring Cloud,接口的呼叫都會重試,因而接口需要實現冪等。
訪問外部服務的包,這將所有對外的訪問獨立出來,好處一是可以抽象出來,在服務拆分的時候,可能會用到,例如原來支付的邏輯在下單的模塊中,要講支付獨立出來,則會有一個抽象層,涉及到老的支付方式,還是呼叫本模塊中的邏輯,涉及到新接入的支付方式使用遠程呼叫,有了這一層方便的多。好處二是可以實現熔斷,當被呼叫的服務不正常的時候,在這裡可以傳回托底資料。好處三是可以實現Mock,這樣對於單元測試來講非常好,不用依賴於其他服務,就可以自己進行測試。
DTO和訪問資料庫的包,看到了這些資料結構,會幫助程式員快速掌握代碼邏輯,不知道大家有沒有這個體驗,你去看一個開源軟體的代碼,首先要看的是他的資料結構,資料結構和關係看懂了,代碼邏輯就比較容易懂了,如果資料結構沒看懂,則光看邏輯,就容易雲里霧裡的。
還有就是核心的代碼邏輯和對接口的實現。在這裡面是軟體代碼設計的內功所在,但是卻不是流程能夠控制的。


六、有關接口設計規範

上面也說過了,Dubbo和Spring Cloud會對接口進行重試,因而接口需要保持冪等。也即多次呼叫,應該產生一致的結果,例如轉賬1元,因為呼叫失敗或者超時重試的時候,最終結果還應該是轉賬1元,而非呼叫兩次變成轉賬2元。
冪等判斷儘量提前,可以使用ID作為判斷條件。
接口的實現應該儘量避免阻塞,可以使用異步方式提升性能。
接口應該包括能夠區分不同情況的異常,而非丟擲寬泛的Exception,不能吞掉異常。
接口的實現要有足夠的容錯性,以及對不同版本的兼容性。當要引入新接口的時候,使用先添加,後刪除的方式。
接口應該有良好的註釋。


七、有關代碼設計

對於代碼的設計,這裡常說的就是SOLID原則。
S是單一責任原則,如果你的代碼中有一個類行數太長,可能你需要重新審視一下,是不是這個類承擔了過多的責任。
O是開放關閉原則,比較拗口,對擴展開放,對修改關閉。思想是對於代碼的直接修改是非常危險的事情,因為你不知道這段代碼原來被誰用了,而且當時候用的時候,面臨的情況都是怎樣的。因而不要貿然修改一段代碼,而是選擇用接口進行呼叫,用實現進行擴展的方式進行。當你要實現一段新的功能的時候,不要改原來的代碼,也不要if-else,而是應該擴展一種實現,讓原來的呼叫的代碼邏輯還是原來的,在新的情況下使用新實現的代碼邏輯。
L是里氏替換原則,如果基於接口進行編程,則子類一定要能夠擴展父類的功能,如果不能,說明不應該繼承與這個接口。例如你的實現的時候,發現接口中有一個方法在你這裡實在對應不到實現,不是接口設計的問題,就是你不應該繼承這個接口,絕不能出現not implemented類似之類的實現方法。
I是接口隔離原則,接口不應該設計的大而全,一個接口暴露出所有的功能,從而使得客戶端依賴了自己不需要的接口或者接口的方法。而是應該講接口進行細分和提取,而不應該將太過靈活的引數和變數混雜在一個接口中。
D是依賴倒置原則,A模塊依賴於B模塊,B模塊有了修改,反而要改A,就是依賴的過於緊密的問題。這就是常說的,你變了,我沒變,為啥我要改。如果基於抽象的接口編程,將修改隱藏在後面,則能夠實現依賴的解耦。
以上是模塊內部常見的設計原則,對於模塊之間,則是對於雲原生應用常說的十二原則。

詳情可看《雲原生時代下的12-factor應用與實踐》。


八、有關配置檔案

在代碼倉庫中,還需要管理的是配置檔案,往往在src/main/resource下麵。
配置的管理原來多使用profile進行管理,對於dev、test、production使用不同的配置檔案。
然而當配置非常多的時候,比較的痛苦,而且配置不斷的修改,每次上線各種配置需要仔細的核對,眼睛都花了,才敢上線。
我們可以將配置分為下麵的三類:
  • 內部配置項(啟動後不變,改變需要重啟)

  • 集中配置項(配置中心,可動態下發)

  • 外部配置項(外部依賴,和環境相關)

在梳理配置的時候,可以按著三類歸類,分門別類管理。
在使用了容器之後,很多的內部配置項可固化在配置檔案中,放在容器鏡像中,需要啟動的時候修改的,則通過環境變數,在啟動容器的時候,在編排檔案中進行修改。
依賴的內部服務的地址,在容器平臺Kubernetes裡面,可以通過配置服務名進行服務發現,僅僅在配置檔案中配置名稱就可以了,不用配置真實的地址,Kubernetes可以根據不同的環境,不同的namespace自動關聯好,大大簡化了配置。當然也可以用服務中心Dubbo和Spring Cloud做內部服務的相互發現。
依賴的外部服務的地址,例如MySQL、Redis等,往往不同的環境不同,也可以通過配置Kubernetes外部服務名的方式進行,而不用一一核對,擔心測試環境連上了生產環境的IP地址。
還有一些集中配置項,需要動態修改的,例如限流,降級的開關等,需要通過統一的配置中心進行管理。


九、有關資料庫版本

代碼可以很好的版本化,應用也可以用鏡像進行原子化的升級和回滾。
唯一比較難做到的就是資料庫如何版本化管理。
有一個工具Flyway可以比較好的做這件事情。
在代碼中,Flyway需要有以下的結構:
  • 在src/db/migration中有SQL檔案,命名規則,如:V1__2017_4_13.sql ,V開頭+版本號+雙下劃線+描述,後綴為sql。

  • 增加flyway的java類,實現migration方法。

在資料庫中,Flyway會自動增加SCHEME_VERSION表。
當服務啟動的時候,Java類的migration方法會被呼叫,它會按照指定路徑中sql陳述句的版本號進行排序並且按照這個排序去執行,當每一個SQL檔案被執行後,元資料的表就會按照格式進行更新。

當服務重啟的時候,Flyway再次掃描SQL的時候,它就會檢查元資料表中遷移版本,如果要執行的遷移腳本的版本小於或者等於當前版本,Flyway將會忽略,不再重覆執行。
但是Flyway從來不解決資料庫升級和回滾的代碼兼容性問題。
太多的人問這個問題了,代碼可以灰度發佈,資料庫咋灰度?代碼升級了,發現不對可以回滾,資料庫咋回滾。
如果可以停服的話,自然是使用資料庫快照備份的方式進行回滾了。
如果不可以停服,沒辦法,只有在代碼層面做兼容性。每次涉及資料庫升級的都是大事情,代碼當然應該有個開關,保證隨時可以切回原來的邏輯。
本文轉載自公眾號:劉超的通俗雲計算,點擊閱讀原文

Kubernetes 實戰培訓

本次培訓內容包括:Docker容器的原理與基本操作;容器網絡與儲存解析;Kubernetes的架構與設計理念詳解;Kubernetes的資源物件使用說明;Kubernetes 中的開放接口CRI、CNI、CSI解析;Kubernetes監控、網絡、日誌管理;容器應用的開發流程詳解等,點擊識別下方二維碼加微信好友瞭解具體培訓內容

3月23日開始上課,點擊閱讀原文鏈接即可報名。
赞(0)

分享創造快樂