微服務給DevOps帶來了什麼？

作者 | Juni Mukherjee

原文 | https://dzone.com/articles/what-can-microservices-bring-to-devops

一些企業總是避開定期投資架構解耦和現代化技術，因此現在無法擺脫巨大的產品架構，使得發布變成無法預測。

一個龐大僵化的系統就像個「泥石流」，滾下山坡，越滾越大。下面就是這個龐然大物的缺點：

1. 如果當系統笨重時，密密麻麻的數據準備生產，某物崩潰的概率會高於假如它是個更易於管理的規模。

2. 考慮到整體的密度，大團隊都有責任，有時候跨越多個團隊。分擔責任有時候意味著沒人負責。

3. 更糟的是，這個龐然大物每次要變更時都需要經過構建、打包和測試這些步驟，即使是個微小的變更，且它只佔整個整體的一小部分。

如果這個龐然大物面臨一個需要緊急修復的生產問題，它可能不會給團隊帶來安心，因為他們知道，固定版本的相同巨石已經開始慢慢地滾下同樣危險的山丘。如果第一個補丁不起作用，我們會回到起點， 一部分、二部分、三部分，然後重複，直到產品按照預期執行。聽起來很糟是吧？它的確是。

進入微服務和DevOps

沒有一個玩笑能夠概括全球所有不同科技公司的意圖。然而卻有一個普遍的真理。

全世界的所有組織都試圖頻繁地發布高質量的產品，來提高客戶的滿意度。

作為Atlassian Bitbucket的開發人員，我非常熟悉這個事實，因為我們的目標是幫助各地的技術組織更快地交付更好的軟體。這就是為什麼我們不斷改進產品，並在我們的套件中增加新選項——提供工具，讓它更容易、有效地交付高質量的產品。

在這方面，我們將回顧以下內容：

DevOps Microservices好處

它們的共存如何提高產品發布的速度、質量和可預測性。

01

微服務架構和DevOps允許分散開的團隊控制他們自己的命運

集中允許一組人在技術堆棧、工具和標準上做決定，而其餘的組織必須遵守這些決策。雖然這聽起來像是個新方法來減少重複和成本，但它可能導致沉悶和成員士氣低落。為了促進創新，我們必須授權小團隊以自己的速度進行創新，並控制自己的命運。

微服務架構就是關於把一件事做好，從設計一個由許多「服務」集中到一個的龐然大物中，這是一種範式轉變。對龐大系統的扼殺催生了更小的微服務，並加速了龐大笨重團隊的瓦解，研發變成了多個更小（更靈活）的團隊。

由於微服務是圍繞獨立業務功能組織的，所以可以用不同的編程語言進行開發。這裡的關鍵概念是建立定義良好的、清晰的介面，介面決定了這些模塊化的多語言服務之間的交互。這樣可以讓較小的團隊自由選擇自己的標準和成功指標，同時也滿足了組織KPI。介面決定了服務（以及團隊）如何交互，從而讓架構決定組織，而不是反過來。這也是康威定律的精髓所在：

"Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization"s communication structure."

此外，權力分散也正好符合DevOps的核心原則，縮小了兩者之間的差距：

1. UI、中間層和後台專家，他們傾向於在自己的筒倉中操作。

2. 業務、產品管理、開發、QA、發布、安全、運營，以及其他成員，這些人都傾向於在自己的部門工作。

最重要的是，微服務架構和DevOps都支持產品模型和項目模型，即5-7個成員團隊設計、構建、測試、發布、監控和維護他們在開發/測試、階段和生產上的應用。

02

區分開的服務可以作為獨立的、可展開的構件發布

大多數組織都傾注於設計和實施有彈性的持續交付管道，這可以幫助他們：

在一個安全的、受保護的和可審計的方式下測試新功能

很快從失敗中恢復，而不去影響客戶

如果系統是由多個子系統組成，並且只能作為一個整體來發布，「一個鏈條的強度由它最薄弱的一環決定」，這聽起來很老套。相反，微服務架構本質上是一套具有清晰邊界的服務。通常，每個微服務都轉換成一個可獨立部署的（版本化）構件，生成一個線性管道結構。每個模塊服務都是圍繞一個業務功能組織的，它可以（也應該）獨立發布，來提高開發人員的生產力和團隊速度。這些區分開的（或組件化的）服務並不是為了成功和讓更快的團隊能夠領先於較慢的團隊而綁在他們後面。

儘管整體架構模式是成功的，但微服務提供的模塊性使發布能夠快速地以增量的方式進行。DevOps也支持小批量的規模，並允許小型團隊擁有服務並將其交付。

然而，我們再次看到，微服務和DevOps在和諧地發揮作用，以幫助組織擴大規模。

03

微服務和DevOps提高了測試周期，並且加速推向市場

一些組織常常面臨激烈的競爭，或者至少是保持不掉隊。他們想建立可持續的商業模式，這樣就可以讓新想法迅速付諸實踐，而不會消磨團隊精力。然而，用龐大僵化的系統來實現這一目標是有可能的，但與顆粒狀的微服務相比，可能性要小得多。下面就是原因。

一個龐然的系統經常導致一場「龐大測試」：

系統在重要的一段時間內被設計和實施，在此期間團隊成員可能多次改動。

可能不允許單獨測試，因為測試用例、設計測試數據和測試配置沒有被設計用來獨立執行。

由於添加新的測試用例，每個新版本就越來越大。有時候，即使是在生產中不常用的功能，也會有緩慢的、歸檔的過期測試。在測試存檔過程中可能存在不確定性，因為可能沒有一個人完全理解系統架構。

所有相關的或其他的測試，在系統每次變更的過程中執行，以確保密集的功能不會在不經意間退化。這將組織的測試周期時間以指數性的增加，測試執行時間決定是否進行釋放或中止。測試周期時間與功能生成時間成正比，就是發布一個功能到生產所需的時間。反過來，這又為新的業務功能發布到市場增加時間，這讓組織容易受到干擾。

顆粒度的微服務通過獨立的、可部署版本的構建被發布到生產中，這些構件分別被驗證。微服務相互作用，提供特定的客戶用例，因此需要智能集成測試。在集成測試期間，這些鄰近的服務中有一些是由它們的測試替身和清晰定義的合約來表示的。測試替身和合約應該被重視，並且應該由擁有、交付和維護真實服務和介面的小團隊擁有。

底線是：我們應該避免一個高度集成的驗證環境，在這個環境中，所有的子系統都集成到一個系統或幾個小型系統中，然後作為一個整體進行驗證和發布。DevOps提倡小規模和增量的批量大小，而微服務架構幫助我們以一種細粒度的方式開發、測試和發布服務。它避免了組合（或組裝）模式，並為單獨的變更執行選擇測試套件，而不是採用全或無方法。

總結

微服務和DevOps關鍵的結論是：

1.它們是相輔相成的

2.現場試驗

3.促進採用

如果組織被迫選擇其中一個，或如果它們在某種程度上有不一致的話，那將非常可惜。此外，微服務架構和DevOps簡化了軟體的交付方法，如持續交付和持續部署，並幫助生成可伸縮的交付管道。

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！