在現代應用中使用微服務不再是一個可劃分優劣的因素，但是對於希望在當今市場保持技術進步性的組織來說，這是一項迫在眉睫的任務。技術創新的步伐讓企業變得更快，更智能，更精簡，這意味著要實現IT現代化並保持競爭優勢並擴大業務規模。
雖然許多組織都講述了他們從單一應用程序轉向分佈式微服務的故事，但Sumo Logic的故事甚至更加激進。在開始Sumo Logic之前，我的團隊花費了將近10年的時間來構建和擴展類似的解決方案，僅在單片機架構上作為企業軟件提供。我們啟動了Sumo Logic方案，專門以新的方式構建下一代日誌管理系統：作為分佈式，可擴展的多租戶服務。
我們從逐漸實施用於日誌和指標的超大型數據處理系統的經驗中汲取了許多關鍵經驗教訓。為了避免我們必須堅持不懈的困難，我在這裡提供了七條關於如何利用微服務來擴展業務的技巧。
＃1. 執行生產開發單元
首先，你需要建立你的團隊。我們目前應用一種稱為產品開發單元（PDU）的模型。 PDU是擁有一套微服務的完整單元。這有助於讓較小的團隊專注於特定的項目，並避免因在一組微服務中擁有太多人手而產生的複雜問題。這實際上是由傑夫貝佐斯在亞馬遜出名的“雙比薩團隊”規則的想法，這意味著如果你不能給一個團隊提供兩個比薩餅，那麼這個團隊就太大了。
雖然PDU在其產品特定部分的操作知識和專業知識相當強大，但在需要推出橫向更改時也存在不足。 （涉及我們所有微服務的項目的一個例子是從Java 7過渡到Java 8.）讓所有PDU執行橫向更改並不容易，但是如果您的團隊有效地進行溝通，則可以完成。我們通常提名一個人去管理這些變化的並負責與下屬人員交流，並且該人員將微服務的顏色編碼列表發送到相對較大的分發列表。人們不希望在RED中看到他們的服務出現。
＃2. 改變你的組織結構以鼓勵所有權
我們劃分團隊的方式隨著時間而改變。在我們剛開始時，組織結構是四五個開發人員和一些微服務。現在團隊規模變得更大，我們有40或50個微服務。最初，由一個人或一個團隊管理每項服務沒有意義，因為架構仍在迅速發展。但隨著團隊的成長，以及架構的基石落地，我們在幾個團隊中劃分了服務。
構建軟件的人員要完全管理它是非常重要的。換言之，他們不僅構建軟件，而且還測試，部署和運行它。他們負責整個生命週期。我們喜歡這種問責制。另一方面，人們也需要有足夠的自由來完全管理自己的工作，並且有權決定是否對軟件做出決定。如果他們在半夜被代碼工作吵醒，那麼他們也需要被信任來做出一些特殊決定。
當涉及到這一點時，這與社會中的聯邦制度和社會文化非常相似，在這個制度中，圍繞多個獨立單位而建立的系統共同實現了更大的目標。這在一定程度上限制了單位的獨立性，但在較小的群體中，他們有權在更高級別的指導原則下自行作出多項決策。
＃3. 確定服務邊界
在建立服務界限時，其中一些歸結為純粹的直覺。然而，剛開始之時，與其他人一樣，我們拿過一塊白板，開始標識系統的主要組件，並在它們周圍畫框。
起初，我們為微服務建立了一個硬邊界 - 這是我們非常堅定的戰略。我們最初擁有單獨的軟件倉庫，即使在我們剛剛有三個微服務的時候也是如此。在以前的單片系統工作之前，我們已經被搞奔潰了，因為人們往往無法遵循代碼組織的基本約定，比如哪些代碼應該放入哪個Java包中，哪些包不應該調用其他包。所以為了保持低耦合，我們在這一點上是激進的。我們最終得到了一個龐大的存儲庫和最終柔和的邊界，但工作至今，都是因為我們教導所有團隊都尊重邊界的結果。
從最初考慮系統的角度來看，領域經驗也有幫助 - 最初的團隊在構建日誌管理系統方面有一定的經驗。但是，當然有一些事情我們也弄錯了。例如，在某一時刻，我們最初將數據索引和搜索分開，但實際上它們應該是相同的模塊或相同的服務。在這些集群之間交換基本相同的數據是一個非常繁瑣的過程，除了增加延遲外，它還會對您的架構產生不良影響。事實上，我們花了兩三年的時間才弄清楚這個初步決策對架構的核心部分有多大的影響，但一旦我們做到了，它就會讓我們的開發人員的工作變得更加輕鬆。
＃4. 謹慎對待服務器升級的時機
我無法誇大這一點：立即升級所有服務是一個壞主意。曾經有一段時間，我們曾經部署過幾個星期，看到有些東西出毛病，回滾，然後重新開始。然後我們部署了，看到另一件事情又出毛病，回滾了，再次從頭開始。在某一時刻，我們連續三，四，五週做了這個。我們最終意識到這是荒謬的，必須有一種更有效的方式去實現它。當然，對今天的人來說這是常識，但早在2010年，那時候人們必須自己發現這些基本事實。
當時，我們已經有大約25個服務和一個約15或20人的團隊。另一種方法是通過服務推出升級服務，這似乎同樣荒謬。如何升級服務，重啟服務，並確保它在兩小時的維護時間內正常運行25次？簡短的回答：不可能。
我們在應付某些情況的時候。我們發明了一個名為“組裝團隊”的概念，這是25個服務的小組。這兩項服務中的任何一項都可以一起升級，這對團隊來說是一個更現實的任務。
＃5. 擁抱多種測試方式
使用微服務進行測試很困難，特別是一旦您轉向持續部署模型。為了解決這個問題，我們投入了大量的資金 - 並且繼續投入相當大的資金進行整合和單元測試，並且我們使用幾種不同的方法來測試每個單獨的情況。
一種方法就是我們所說的“本地部署”，在這種方式下，您可以在筆記本電腦上運行大部分服務以獲得完全正常運行的系統。但是，目前帶有16GB內存的筆記本電腦已經達到了極限，因此不容易擴展。
第二種方式就是我們所說的“個人部署”。這裡的每個人都有自己的AWS賬戶，我們的部署工具完全自動化，您可以在10分鐘內在AWS中建立一個完整的Sumo Logic實例。這是項目百分之百誕生在AWS雲服務中的好處。
第三種方式就是我們所說的“樁部署”，這是我們建立的一個樁模塊的名稱。樁部署可以讓你寫微型服務的樁代碼，表現得好像他們是真正的服務，並且在我們的服務發現中自我通知，就好像他們是真正的服務一樣。但是，它們是一個虛擬的實現，它可以執行一些您可以控制的操作。這比運行所有這些服務要輕巧得多。
例如，如果您正在使用搜索組件，則始終需要知道哪些客戶存在這個服務。您還需要知道用戶和分區的服務，但您並不需要真正的版本及其所有的複雜性和功能。你只需要假裝在這裡有用戶的東西。我們在這種情況下使用樁部署。
＃6. 加上安全防線和安全中心
客戶越來越重視對GDPR，HIPAA，PCI等認證的遵守。
鑑於此，安全必須從頭開始建立。我們的部署工具是模型驅動的，並且該模型不僅瞭解集群和微服務等內容，而且還了解它們如何相互交流。我們可以從該模型生成一套相當緊密的安全控制機制。
例如，在網絡層面上，我們可以嚴格根據誰與誰談話的理解來生成防火牆規則。這是AWS為我們做了一些繁重工作的地方之一。
從安全的角度來看，建立在雲服務上可能是有利的。你根本無法手動做任何事情，所以一切都必須自動化。一旦你開始編寫和自動化所有的東西，默認情況下將所有東西都捆綁起來會更容易。
但是安全不僅僅是架構和代碼 - 實際上它周圍有很多過程。具體而言，客戶需要查看審計報告。通過查看和審核對控件的要求，然後對其進行測試，您可以將審核過程轉化為優勢。然後，當審計員再次測試時，它們無形中建立了一個良好的習慣。
＃7. 使用維基百科來滿足您組織的特定需求
總結經驗意味著會積累大量信息，並且通常很快。許多開發團隊轉向使用他們的內部維基頁面來記錄文檔和工作實踐經驗。但是，如果任由組織中的任何人進行編輯，這些內容可能會變得雜亂無章。像這樣的內容很難管理和維護，因此最好指定負責維護組織維基的管理人員。
雖然指定管理人員可能感覺任務過於集中或者負擔過重，但要激勵一組開發人員去隨時更新維基是很困難的。此外，雖然技術人員（尤其是初創公司）常常擁有很多頭銜，但作為領導應優先考慮去維護此文檔和最佳實踐方式。
維基版主應該對他們策劃的內容進行策略性的制定。不要將所有東西都包含在內，而應將其限制在開發人員需要了解的關鍵概念上。太多的內容可能會讓人無所適從，並導致利用率不足。
使用微服務分而治之
微服務架構的核心是分而治之。需要建立的分佈式系統將變得複雜 - 這是一個給定的問題。解決這個問題的一種方法是試圖限制任何給定部分的複雜性，並且通過遵循這七個技巧，組織可以更輕鬆地進行處理。
採用微服務架構是擴展系統和人機系統的最佳方法之一，尤其是考慮到功能性（特別是非功能性）需求的複雜性。雖然從龐大的系統過渡到微服務似乎是一項艱鉅的任務，但如果您能夠圍繞這一想法動員開發人員並掌握相關所有知識，不僅可以輕鬆管理過渡期，還可以簡化擴展的過程。這對開發人員來說揹負了沉重的負擔，並最終構建了一個更有效的系統，以更好地滿足客戶的需求。
閱讀更多 IT技術之家 的文章
