本文由 網易雲 釋出。
作者：劉超，網易雲解決方案架構師
一、持續整合對於微服務的意義：拆之前要先解決合的問題
在很多微服務化的文章中，很少會把持續整合放在第一篇，因為大多數的文章都會將如何拆的問題，例如拆的粒度，拆的時機，拆的方式。
為什麼需要拆呢？因為這是人類處理問題的本質方式：將一個大的複雜問題，變成很多個小問題解決。
所以當一個系統複雜到一定程度，當維護一個系統的人數多到一定程度，解決問題的難度和溝通成本大大提高，因而需要拆成很多個工程，拆成很多個團隊，分而治之。
然而當每個子團隊將子問題解決了，整個系統的問題就解決了麼？你可以想象你將一輛整車拆成零件，然後再組裝起來的過程，你就可以想象拆雖然不容易，合則更難，需要各種標準，各種流水線，才能將零件組裝稱為車。
我們先來回顧一下拆的過程。
最初的應用大多數是一個單體應用：
一個Java後端，後面跟一個資料庫，基本上就搞定了。
隨著系統複雜度的增加，首先Java程式需要做的是縱向的拆分。
- 首先最外面是一個負載均衡，接著是接入的Nginx，做不同服務的路由。
- 不同的服務拆成獨立的程式，獨立部署，每個服務使用自己的資料庫和快取，解決資料庫和快取的單點瓶頸。
- 資料庫使用一主多從的模式，進行讀寫分離，主要針對讀多寫少的場景。
- 為了承載更多的請求，設定快取層，將資料快取到Memcached或者Redis中，增加命中率。
- 當然還有些跨服務的查詢，或者非結構化資料的查詢，引入搜尋引擎，比關係型資料庫的查詢速度快很多。
在高併發情況下，僅僅縱向拆分還不夠，因而需要做真正的服務化。
一個服務化的架構如圖所示。
- 首先是接入層，這一層主要實現API閘道器和動態資源和靜態資源的分離及快取，並且可以在這一層做整個系統的限流。
- 接下來是Web層，也就是controller，提供最外層的API，是對外提供服務的一層。
- 下面是組合服務層，有時候被稱為編排層，compose層，是實現複雜邏輯的一層。
- 下面是基礎服務層，是提供原子性的基本的邏輯的一層，他下面是快取，資料庫。
- 服務之間需要治理，需要相互發現，所以一般會有dubbo或者springcloud一樣的框架。
- 對所有的服務，都應該有監控告警，及時發現異常，並自動修復或者告警運維手動修復。
- 對於所有的服務的日誌，應該有相同的格式，收集到一起，稱為日誌中心，方便發現錯誤的時候，在統一的一個地方可以debug。
- 對於所有的服務的配置，有統一的管理的地方，稱為配置中心，可以通過修改配置中心，下發配置，對於整個叢集進行配置的修改，例如開啟熔斷或者降級開關等。
通過簡單的描述，大家可以發現，從一個簡單的單體應用，變成如此複雜的微服務架構，除了關心怎麼拆的問題，還必須關注：
- 如何控制拆的風險
- 如何保證程式碼質量
- 如何保證功能不變，不引入新的Bug
答案當然就是整合，從一開始就整合，並且不斷的整合，反覆的將拆分的模組重新組合，看看是否能夠順利組合起來，並且保證功能的不變。
要是不沒事兒就組合一下，天知道幾個月以後還能不能合的起來。
別忘了程式是人寫的，你和你媳婦長時間不溝通都對不上默契，別說兩個程式設計師了。
二、持續整合就是不斷的嘗試在一起
整合就是在一起。
為什麼需要一個統一的程式碼倉庫Git來做程式碼管理呢？是為了程式碼整合在一起。
為什麼需要進行構建build呢？就是程式碼邏輯需要整合在一起，編譯不出錯。
為什麼要單元測試呢？一個模組的功能整合在一起能夠正確工作。
為什麼需要聯調測試Staging環境呢？需要將不同模組之間整合在一起，在一個類生產的環境中進行測試。最終才是部署到生產環境中，將所有人分開做的工作才算真正的合在了一起。
持續整合就是制定一系列流程，或者一個系列規則，將需要在一起的各個層次規範起來，方便大家在一起，強迫大家在一起。
三、持續整合，持續交付，持續部署，敏捷開發，DevOps都啥關係？
這些概念都容易混淆，他們之間是什麼關係呢？
敏捷開發Agile是一種開發流程，是一種快速迭代的開發流程，每個開發流程非常短，長到一個月，短到兩個星期，就會是一個週期，在這個週期中，每天都要開會同步，每天都要整合。正是因為週期短，才需要持續的做這件事情，如果一個開發週期長達幾個月，則不需要持續的整合，最後留幾個星期的整合時間一起做也是可以的，但是這樣就不能達到網際網路公司的快速迭代，也是我們常常看到傳統公司的做法。
持續整合往往指對程式碼的提交，構建，測試的過程，也就是上述的在一起的過程。
持續交付是指將整合好的交付物，例如war，jar，或者容器映象，部署在聯調環境，或者預發環境的過程。
持續部署是指將交付物持續部署在生產環境的過程。
我們常說CICD，CD有時候指的是Delivery交付，有的是指Deployment部署，對於非生產環境，自動部署是沒有問題的，對於生產環境，往往還是需要有專人來進行更為嚴肅的部署過程，不會完全的自動化。
接下來就是DevOps，DevOps不只是CICD，除了技術和流程，還包含文化。例如容器化帶來的一個巨大的轉變是，原來只有運維關心環境的部署，無論是測試環境，還是生產環境，都是運維搞定的，而容器化之後，需要開發自己寫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和springcloud都會重試介面。介面是否會升級，是否帶版本號
- 是否有單元測試
當然還有一些不容易一眼看出來的，可以通過一段時間通過統一的程式碼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裡面，被服務端和客戶端共同依賴，但是使用了springcloud的restful方式就不用了，只要在各自的程式碼裡面定義就可以了，會變成json的方式傳遞，這樣的好處是當jar有多個版本依賴，需要升級的時候，關係非常複雜，難以維護，而json的方式比較好的解決了這個問題。
這個模組提供了哪些介面，只要到API介面這個package下面找就可以了。因為無論是Dubbo還是springcloud，介面的呼叫都會重試，因而介面需要實現冪等。
訪問外部服務的包，這將所有對外的訪問獨立出來，好處一是可以抽象出來，在服務拆分的時候，可能會用到，例如原來支付的邏輯在下單的模組中，要講支付獨立出來，則會有一個抽象層，涉及到老的支付方式，還是呼叫本模組中的邏輯，涉及到新接入的支付方式使用遠端呼叫，有了這一層方便的多。好處二是可以實現熔斷，當被呼叫的服務不正常的時候，在這裡可以返回託底資料。好處三是可以實現Mock，這樣對於單元測試來講非常好，不用依賴於其他服務，就可以自己進行測試。
DTO和訪問資料庫的包，看到了這些資料結構，會幫助程式設計師快速掌握程式碼邏輯，不知道大家有沒有這個體驗，你去看一個開源軟體的程式碼，首先要看的是他的資料結構，資料結構和關係看懂了，程式碼邏輯就比較容易懂了，如果資料結構沒看懂，則光看邏輯，就容易雲裡霧裡的。
還有就是核心的程式碼邏輯和對介面的實現。在這裡面是軟體程式碼設計的內功所在，但是卻不是流程能夠控制的。
六、有關介面設計規範
上面也說過了，Dubbo和Springcloud會對介面進行重試，因而介面需要保持冪等。也即多次呼叫，應該產生一致的結果，例如轉賬1元，因為呼叫失敗或者超時重試的時候，最終結果還應該是轉賬1元，而非呼叫兩次變成轉賬2元。
- 冪等判斷儘量提前，可以使用ID作為判斷條件。
- 介面的實現應該儘量避免阻塞，可以使用非同步方式提升效能。
- 介面應該包括能夠區分不同情況的異常，而非丟擲寬泛的Exception，不能吞掉異常。
- 介面的實現要有足夠的容錯性，以及對不同版本的相容性。當要引入新介面的時候，使用先新增，後刪除的方式。
- 介面應該有良好的註釋。
七、有關程式碼設計
對於程式碼的設計，這裡常說的就是SOLID原則。
- S是單一責任原則，如果你的程式碼中有一個類行數太長，可能你需要重新審視一下，是不是這個類承擔了過多的責任。
- O是開放關閉原則，比較拗口，對擴充套件開放，對修改關閉。思想是對於程式碼的直接修改是非常危險的事情，因為你不知道這段程式碼原來被誰用了，而且當時候用的時候，面臨的情況都是怎樣的。因而不要貿然修改一段程式碼，而是選擇用介面進行呼叫，用實現進行擴充套件的方式進行。當你要實現一段新的功能的時候，不要改原來的程式碼，也不要if-else，而是應該擴充套件一種實現，讓原來的呼叫的程式碼邏輯還是原來的，在新的情況下使用新實現的程式碼邏輯。
- L是里氏替換原則，如果基於介面進行程式設計，則子類一定要能夠擴充套件父類的功能，如果不能，說明不應該繼承與這個介面。例如你的實現的時候，發現介面中有一個方法在你這裡實在對應不到實現，不是介面設計的問題，就是你不應該繼承這個介面，絕不能出現not implemented類似之類的實現方法。
- I是介面隔離原則，介面不應該設計的大而全，一個介面暴露出所有的功能，從而使得客戶端依賴了自己不需要的介面或者介面的方法。而是應該講介面進行細分和提取，而不應該將太過靈活的引數和變數混雜在一個介面中。
- D是依賴倒置原則，A模組依賴於B模組，B模組有了修改，反而要改A，就是依賴的過於緊密的問題。這就是常說的，你變了，我沒變，為啥我要改。如果基於抽象的介面程式設計，將修改隱藏在後面，則能夠實現依賴的解耦。
以上是模組內部常見的設計原則，對於模組之間，則是對於雲原生應用常說的十二要素原則。
八、有關配置檔案
在程式碼倉庫中，還需要管理的是配置檔案，往往在src/main/resource下面。
配置的管理原來多使用profile進行管理，對於dev, test, production使用不同的配置檔案。
然而當配置非常多的時候，比較的痛苦，而且配置不斷的修改，每次上線各種配置需要仔細的核對，眼睛都花了，才敢上線。
我們可以將配置分為下面的三類：
- 內部配置項(啟動後不變，改變需要重啟)
- 集中配置項(配置中心，可動態下發)
- 外部配置項(外部依賴，和環境相關)
在梳理配置的時候，可以按著三類歸類，分門別類管理。
在使用了容器之後，很多的內部配置項可固化在配置檔案中，放在容器映象中，需要啟動的時候修改的，則通過環境變數，在啟動容器的時候，在編排檔案中進行修改。
依賴的內部服務的地址，在容器平臺kubernetes裡面，可以通過配置服務名進行服務發現，僅僅在配置檔案中配置名稱就可以了，不用配置真實的地址，kubernetes可以根據不同的環境，不同的namespace自動關聯好，大大簡化了配置。當然也可以用服務中心Dubbo和Springcloud做內部服務的相互發現。
依賴的外部服務的地址，例如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從來不解決資料庫升級和回滾的程式碼相容性問題。
太多的人問這個問題了，程式碼可以灰度釋出，資料庫咋灰度？程式碼升級了，發現不對可以回滾，資料庫咋回滾。
如果可以停服的話，自然是使用資料庫快照備份的方式進行回滾了。
如果不可以停服，沒辦法，只有在程式碼層面做相容性。每次涉及資料庫升級的都是大事情，程式碼當然應該有個開關，保證隨時可以切回原來的邏輯。
延伸閱讀：
瞭解網易雲如何通過雲端計算產品支援微服務化實踐的設計，歡迎點選這裡。
瞭解單體應用改造的全流程，敬請參閱《雲原生應用架構實踐》，網易雲基礎服務架構團隊著，全程詳解單體到分散式服務化架構的演進，由淺及深、深入淺出梳理工程化、DevOps、雲資料庫、微服務架構和同城多活等相關內容。
瞭解網易雲：
網易雲官網：www.163yun.com/
新使用者大禮包：www.163yun.com/gift
網易雲社群：sq.163yun.com/