那些微服務和技術堆棧教咱們的事

時間 2019-11-29

標籤些微服務技術堆棧咱們简体版

原文原文鏈接

Ashish Sharma在本文中將談談企業技術堆棧主流是如何一步步走向微服務架構的，並分享一些經驗教訓。html

過去的技術堆棧以下圖所示：node

在應用層，咱們有一個用Windows form和WPF編寫的桌面客戶端。應用與服務層對話，而服務層是徹底用c#編寫的SOA體系結構。這是咱們（當時）惟一可使用的語言。它們是經過WCF相互通訊的單片有狀態服務。咱們使用SQL server做爲後端存儲。全部這些都在內部部署，這意味着咱們的客戶購買咱們的軟件並將其託管在本身的硬件上。python

我在金融行業工做（股市準確），是公有云的後期採用者。這個行業不喜歡將數據放在公共雲上的想法。我見過的客戶會阻止與外部世界進行任何可能的通訊，以防止數據泄漏。但隨着技術的成熟，種心態已經發生了巨大的變化，公司開始欣賞公有云及其周圍的安全性。大約在同一時間，咱們的利益相關者也決定將產品放在雲上。管理層並無要求遷移現有系統，而是讓咱們有機會從頭開始構建產品。當時公司裏沒有人真正知道如何進行雲開發，咱們最終獲得了這樣的技術堆棧：nginx

咱們的Angular SPA應用，在服務方面，惟一的主要區別是咱們從單一的有狀態C＃服務轉移到經過rabbitMQ相互通訊的單片無狀態C＃服務。咱們繼續使用Sql server做爲後端存儲。git

在某些時候，咱們認爲咱們正在作的事情是行不通的。咱們在錯誤修正和功能上的循環時間很慢，部署很痛苦，須要大量協調。大約在同一時間，微服務正在增長。咱們聽到Netflix/Google/EBay等公司就採用微服務如何改變其業務的事情。遵循這些主題，它可能最初是做爲某個團隊的實驗開始的，但今天變成了主流開發實踐。github

如今的架構看起來像這樣：golang

咱們有數百種不一樣的µ-services用不一樣的語言編寫,.netcore golang、節點和python是最受歡迎的選擇,一切都被部署爲碼頭工人的容器中。服務經過nginx或rabbitmq與每一個服務通訊。每一個服務棧都有本身的CI/CD管道。我這裏沒有全部的組件，但我但願這能讓咱們對今天的狀況有一個很好的瞭解。咱們也有單片棧，這是能夠的，只要沒有積極的開發。任什麼時候候咱們發現須要觸摸單片的時候，咱們都試圖把它分割成一個不錯的服務。今天，咱們在一天內部署了不少次(沒有停機)，咱們能夠更快地迭代特性!在後臺，咱們使用SqlServer、MySql、DynamoDB和redis緩存，這取決於咱們試圖解決的問題。redis

咱們有數百種不一樣的μ服務，用不一樣的語言編寫，.netcore，golang，node和python等等都是很是受歡迎的選擇，全部應用都被部署爲docker容器、服務經過nginx或rabbitmq進行通訊、每一個服務堆棧都有本身的CI/CD管道……固然咱們也有一些一體化架構應用，這些應用的開發並不頻繁。其餘一體化架構應用，咱們會盡可能將其拆分爲微服務架構應用。到如今，咱們已經能夠在一天內屢次部署（零停機時間）並快速迭代功能！在後端，咱們使用SqlServer、MySql、DynamoDB和redis緩存，具體取決於咱們要解決的問題。docker

經驗和教訓

Docker是必須的

這一點如今已經很明顯了，可是對於咱們來講這是一個頗有趣的問題，由於咱們在.net c#堆棧上花費了大量的時間，而.net C#在很長一段時間內是不兼容的。在沒有docker的狀況下，咱們須要處理的開銷太多了，而docker周圍的社區很是致力於消除全部的痛苦，好在今年的dockercon上Docker宣佈徹底支持windows。總的來講，Docker簡化了交付、測試和開發人員體驗。數據庫

容許團隊靈活選擇語言/技術堆棧

爲何要容許團隊靈活選擇語言和技術堆棧？由於他們是最接近問題的人，對如何解決問題有更好的想法。不只從業務邏輯的角度來看，還有他們想要用來解決問題的工具和技術。若是沒法實現徹底的靈活性，至少能夠列出堆棧選擇範圍。一切都是C＃或Java的日子已經一去不復返了。做爲領導者/經理能夠指導他們作出這個決定，但不要爲他們作出這個決定。咱們但願團隊徹底掌控他們正在生產的東西，不只僅是業務邏輯，還有完整的服務。

不要建立服務框架並強制團隊使用它

當咱們開始雲端開發時，每每以相同的企業思惟方式接近它。咱們建立了一個框架團隊，負責編寫一個框架來解決全部框架問題，所以其餘產品團隊沒必要擔憂它，他們能夠專一於業務邏輯。一個問題是咱們爲每一個人創造了二進制依賴問題。產品團隊須要框架二進制文件才能運行其服務。他們遵循相同的模式意味着當他們須要來自其餘產品團隊的東西時，他們經過共享二進制文件來作到這一點。

咱們必須以艱難的方式學習這一點。那麼如今發生了什麼？更好的新興模式是團隊建立服務模板並與其餘團隊共享。一般，團隊擁有兩三種不一樣語言的專業知識，而且他們不斷構建新服務，他們製做服務模板來讓工做輕鬆一些。使用這些模板，他們幾乎能夠當即啓動新服務，而後與其餘團隊共享。如今，當我須要用到一種新語言，首先都會找到已經擁有它的團隊並查看他們擁有的模板。

交付設計

交付設計的問題頗有趣。一般企業中的思惟過程就是這樣 - 團隊有一個問題陳述 - >他們設計解決方案 - >構建它 - >最後以某種方式提供它。

在微服務架構世界中，這種思惟過程是不一樣的。團隊有一個問題陳述 - >首先考慮交付。爲何？由於交付對您的設計方式有很大影響。它能夠幫助您更好地分解您的解決方案意義，讓咱們在問題陳述中說 - 若是有一些很是活躍的和一些不那麼活躍的區域，那麼您可能但願以這種方式分解您的設計並獨立地交付和擴展它們。您不會在數據庫中編寫過多邏輯或參考任何可能會下降您本身的交付速度的依賴項。

老是存在生產缺陷和性能問題須要處理，若是團隊設計了他們的交付解決方案，那麼團隊能夠更快地作出反應。