在本文中，我將詳細介紹在轉向微服務時需要考慮的內容，以及會面臨的一些挑戰。
從頭新建的微服務項目
每當您的團隊從頭開始開發一個新的應用程序時，不需要陷入多年前做出的過時決策和繼承技術債時，感覺很好。現在開發新應用的大多數團隊可能會選擇使用Docker，並採用微服務體系結構來實現速度和敏捷性。
然而，在你開始之前，有以下幾點需要考慮：
1、獨立程度
第一個決定是——你希望你的服務有多獨立?你可選擇下列其中一項：
- 每個服務都與自己的數據庫和UI完全獨立。這與極端的微服務體系結構是一致的，在這種體系結構中，服務實際上不共享任何東西，並且完全解耦。好的方面是，每個微服務的團隊可以選擇最適合他們需求的數據庫。然而，這種方法使得確保所有數據存儲都是同步和一致性變得更加困難。例如，您需要驗證所有數據存儲中都存在相同的UserIDs，並且其中任何一個都沒有丟失。此外，每個團隊都需要複製數據庫管理任務(如備份)。
- 您可以選擇共享一些組件，通常是您的數據庫。這使得跨所有團隊執行標準和確保跨所有服務的數據一致性變得更加容易。然而，這也意味著您的服務沒有完全解耦，如果有人更新了數據表或schema,，其他服務也可能受到影響。
這兩種方法都有利有弊，所以你需要決定你能接受什麼。我們選擇了第二種方法，因為我們不希望處理不一致的數據，然後花時間尋找方法來確保一致性。
2、代碼組織結構
有幾種方法可以組織代碼庫。您可以為每個服務創建一個存儲庫，您可以為所有服務創建一個“mono repo”，併為每個服務創建一個文件夾。我們選擇mono repo方法。
3、技術棧
要為一個單體應用程序確定技術棧已經夠困難了，但是現在必須為每個微服務選擇技術棧。如果您的服務過於異構，那麼在理論上看起來有吸引力的內容在實踐中可能會出現問題。標準化會成為一個問題，牛仔行為（過於自由的選擇）也有可能出現。而且，如果每個團隊都使用完全不同的技術棧，那麼在團隊之間轉換移動就更困難了。
我們建議採用一種平衡的方法，即在應用程序中存在首選的技術堆棧。如果任何團隊想要覆蓋這個默認堆棧，他們應該用贊成和反對的理由來證明他們的決定，為什麼不同的堆棧更適合他們的微服務。您的技術堆棧應該包括編程語言、測試和日誌框架、雲提供程序、基礎設施、存儲和監視等。
4、操作的複雜性
微服務極大地增加了操作複雜性，因為您需要從非常基本的角度重新考慮操作。
你需要考慮以下方面：
- 基礎設施：為微服務定義基礎設施需求，然後為每個微服務提供和維護基礎框架，這增加了一些複雜性，這是大多數操作系統的工程師所不習慣的。另外，隨著這些服務的放大和縮小，基礎設施需要自動提供和降低，因此您需要非常複雜的自動化級別。
- 負載平衡和擴展：您可能需要一個比單體應用程序複雜得多的擴展策略，而單體應用程序總是被擴展(x軸)。使用微服務，您將需要弄清楚是否需要擴展所有服務，或者在需求激增時只擴展一個子集。您的Ops團隊需要了解y軸的擴展，因為微服務方法與it和z軸的擴展是一致的，從而獲得x和y的好處。
- 服務發現：微服務世界中的服務實例的集合由於縮放和升級而動態變化。此外，服務具有動態的網絡位置，因此您需要一種方法來發現新的服務實例。我們推薦像領事這樣的服務登記處，因為它對我們很有效。閱讀更多關於客戶端服務發現、服務器端服務發現和常用服務註冊的列表。
- 監視:必須對每個微服務進行配置和維護，這增加了Ops工程師的複雜性。此外，監視解決方案還必須處理一些場景，其中服務的子集是按比例伸縮的。
在您決定轉向微服務之前，操作複雜性本身應該讓您暫停一下。除非您意識到微服務的挑戰，並有一個解決它們的計劃，否則這將是一個痛苦的過渡。
5、持續交付
我們同意Martin Fowler的觀點，他在他關於微服務權衡的博客文章中寫道：
“能夠迅速部署小型獨立單元對開發來說是一個巨大的利好，但它給運營帶來了額外的壓力，因為6個應用程序現在變成了數 百個小微服務。許多組織會發現處理這樣一群快速變化的工具是非常困難的。這加強了持續交付的重要作用。儘管持續交付對整 體而言是一項有價值的技能，但它幾乎總是值得付出努力去獲得的，對於一個嚴肅的微服務設置來說，這是必不可少的。“
使用微服務的公司，如Netflix和Amazon，有資源為他們的微服務構建自定義的持續交付管道。然而，並不是每個組織都能負擔得起。即使您負擔得起，您也應該考慮，您的時間是花在構建脆弱的、必須為每個微服務定製的自定義自動化上的最佳時間，還是您希望改進自己的產品。
你有三個選擇：
- 確定您不希望支付微服務溢價，並保持單一體系結構
- 咬緊牙關，通過拼湊幾個不同的工具來構建自己的管道，這些工具可以幫助處理工作流的某些部分。這種方法的問題在於，隨著微服務的數量增加，自動化它們所需的時間和精力會以更快的速度增長。
- 使用像Shippable這樣的CD自動化平臺，可以為異構微服務提供90%以上的持續交付。
6、團隊組織
最後但並非最不重要的是，您需要重新組織您的團隊，以確保每個微服務都是獨立地開發、部署和維護的。你不能讓你的工程師在多個微服務上工作，因為這必然會導致一些決策的優化，而這些決策與對每一個微服務的最佳狀態並不相關。
一個獨立的、獨立的團隊應該處理每個微服務。亞馬遜的團隊模式——它應該足夠小，即少於10人。在某些情況下，每個團隊都應該在開發、測試、操作、DB管理、UX甚至產品管理等方面擁有專業知識。這並不意味著每個角色都需要一個獨特的團隊成員，只是需要在團隊中解決它們。例如，DevOps工程師滿足Dev和Ops的雙重角色。類似地，每個團隊也可以有一個編寫spec和定義UX的經理。
上面的方法有一些變化，比如集中項目操作系統、產品管理或平臺團隊。這些文章進一步闡明瞭如何組織團隊。
Microservices現有項目
如果您想將現有的整塊集成到微服務中，您仍然需要考慮上面描述的所有要點。但是，還有一個針對您的情況的額外挑戰。你將需要一種策略來幫助你在各個階段進行過渡。
7、從單體架構到微服務的轉換策略
這是一個廣泛的話題，就像羅馬不是一天建成的，你的過渡需要時間和專注。
簡而言之，你需要做以下事情：
- 實現持續的交付，以便在服務數量開始增長時，您擁有適當的自動化
- 轉移到像GitHub這樣的分佈式源代碼控制系統，這樣團隊就可以獨立地工作，而不會互相影響
- 採用Docker技術，使您的應用程序以獲得可移植性，並能夠在幾秒鐘內將服務向上和向下旋轉
- 始終將新功能構建為微服務
- 逐步轉換現有的組件，從最不復雜的業務功能開始，使用最少的依賴項，然後使用更復雜的功能。
總結
正如您所看到的，採用微服務並不是微不足道的，只有當您看到應用程序的足夠價值時，才應該進行。
閱讀更多 程序你好 的文章
