微服務架構--它適合您的軟體開發嗎?
微服務體系架構提供了一系列技術好處，這些好處有助於軟體專案的開發速度和產品質量，同時也有助於整體業務敏捷性”– Mark Emeis, CA技術公司軟體技術高階總監
自從“微服務”這個術語出現以來，它在軟體開發方面已經取得了進展。微服務，又名微服務體系結構，是面向服務體系結構(SOA)的變體，用於開發大型應用程式，其中服務根據業務領域的具體情況被劃分為多個塊。它支援複雜應用程式的持續交付/部署，使應用程式更易於理解、開發和測試，並且對體系結構的侵蝕更有彈性。微服務體系結構提供了一種以新穎的方式編織現有系統的新方法，以便快速交付軟體解決方案。它是軟體行業中最熱門的話題之一，因為它能夠提供模組化、可伸縮性和可用性;許多企業軟體開發公司都熱衷於採用它。
Microservices究竟是什麼?
微服務能改善組織的文化、技能和需求嗎?為了深入理解微服務，讓我們首先了解相反方法的要點:單體架構。
關於單體軟體的
維基百科說，“一個單一的應用程式描述了一個單層的軟體應用程式，其中使用者介面和資料訪問程式碼從一個平臺合併成一個程式。”
單體架構軟體使用三層結構:
Presentation Layer – 應用程式的最頂層，並描述使用者介面。主要功能是將任務和結果轉換為使用者能夠理解的內容。使用者介面程式碼是用HTML、JavaScript和CSS等客戶端技術編寫的。 Business Layer – 該層做出邏輯決策並執行計算。它處理兩層之間的資料，並使用Spring等技術。 Data Access Layer –在這裡，資訊從資料庫中儲存和檢索。資訊被傳遞到業務層，然後最終傳遞給使用者。它使用像Hibernate這樣的ORM工具來處理資訊。
web應用程式客戶機發送請求，層執行業務邏輯，資料庫儲存應用程式特定的資料，UI向用戶顯示特定的資料。但是，由於它們共享相同的程式碼庫，可能會出現一些問題。
這種型別的體系結構在一段時間內執行良好，但是由於對持續交付的需求不斷增加，這種模型存在多個問題。
單體架構的缺點 Operational Overhead :不同的涉眾使用不同的單體應用程式層;因此，團隊將侷限於特定的領域專家。在表示層工作的團隊專門從事UI技術，但對資料訪問層的知識最少。因此，如果要新增新特性，就需要不同的團隊來協調並交付特定的特性。這導致了從構思到投放市場的更長的時間跨度，並最終影響業務ROI。 Software stack autonomy :它限制了技術選擇，迫使整個層使用單一框架。例如，如果表示層是在HTML框架中編寫的，那麼整個層將在同一個框架中實現。這避免了實現最新的技術，從而導致應用程式程式碼在短時間內變得過時。 Implicit Interface :由於這程式碼是在單個檔案中釋出的，因此應用程式中的一個小更改需要重新構建整個應用程式。因此，不斷進行的應用程式被放下，導致需要重新部署新版本。這種特性導致更新更少，並且不能以應有的速度發展。 Scalability :單體應用程式具有一維可伸縮性;因此無法縮放各個元件。因此，整個應用程式需要縮放，即使大多數應用程式可能不需要縮放。
沒有良好的體系結構開發軟體會給組織帶來很大的成本。例如:如果軟體開發公司採用非模組化的方法開發軟體，其中UI功能和業務功能混合在相同的原始檔中，那麼公司可能需要投入大量資金來支援其在最新的智慧手機原生應用程式中的應用程式。這嚴重影響了軟體的可維護性，增加了上市時間，最終影響了公司的銷售。
單片架構一直是傳統的方法，但是由於伸縮性的限制、維護大型程式碼庫的困難、高風險的升級和大量的前期設定成本，迫使企業或軟體開發公司探索不同的方法。單片應用程式是一個很難解決的難題，並且隨著時間的推移難以理解和擴充套件。
因此，為了避免這些問題，微服務體系結構可以成為救世主!為解決上述複雜性提供了360度扭轉;幫助軟體開發公司在競爭對手中脫穎而出。
微服務體系架構簡介
微服務體系結構是一種軟體開發技術，它將應用程式構造為鬆散耦合服務的集合。每個服務都是自包含的，應該實現單個業務功能。微服務體系結構旨在克服大型應用程式的挑戰、故障和故障。微服務提供了向系統新增彈性的機會，以便元件能夠優雅地處理尖峰和錯誤。這樣，每個涉眾都可以只關注整個應用程式的一個特定元素，使用自己的程式設計風格，而不關心其他元件。微服務中的通訊可以毫不費力地進行，因為它們是無狀態的，並且在定義良好的介面中(請求和響應是獨立的)。
如果應用/軟體是使用微服務方法開發的，它將有助於採用DevOps方法，並將消除部署效率低下，從而縮短上市時間。由於微服務與裝置和平臺無關，因此它能夠開發應用程式，為大多數平臺(包括web、移動裝置、物聯網、平板電腦、可穿戴裝置等)提供增強的使用者體驗。
例如，沃爾瑪加拿大公司在2012年之前就使用了單片架構!該公司在處理600萬次/分鐘的頁面瀏覽量時遇到了問題，這消耗了更多的時間，導致銷售減少。由於這些問題，他們將軟體架構重構為微服務，並在一夜之間發現了即時結果和高轉化率。停機時間最小化，公司能夠使用更便宜的x86伺服器，而不是昂貴的硬體，從而節省了20%-50%的成本。
Microservices 和 SOA
它是SOA的自然演進，各種技術堆疊將技術多樣性引入開發團隊。SOA和微服務都允許將複雜的工作負載分解為更小、更易於管理和獨立的部分。
然而，兩者之間有一些基本的區別。
Microservices vs SOA
關注分離和有界上下文系統的改變創造了新的服務關注持續交付和DevOps使用輕量級協議，如HTTP、REST等。各個微服務之間提供了獨立的資料儲存 MicroservicesSOA 目標最大化的重用性
系統的改變需要修改整體結構
關注持續交付和DevOps
使用簡單的訊息傳遞系統進行通訊使用企業服務匯流排(ESB)進行通訊支援訊息協議
共享的資料儲存
Microservices哲學
微服務的哲學類似於Unix哲學，“只做一件事，做好它”。其特點如下:
執行單個功能的元件化
根據業務能力進行組織
關注產品，而不是過程
分散的治理和資料管理
服務是彈性的、彈性的、可組合的、最小的和完整的
為什麼軟體開發公司應該投資於微服務架構?Improves Fault Isolation
在微服務體系結構中，開發人員確切地知道在何處查詢要解決的問題。如果單個模組受到影響，它可以很容易地拆卸或解決，而不影響應用程式的其他部分;提高應用程式的可用性。這在單片應用中是完全矛盾的;單個元件的故障可能導致整個應用程式崩潰。例如，移動遊戲應用程式(構建在單塊架構上)有不同的元件，比如支付、登入、玩家、歷史等等。如果一個特定的元件開始消耗更多的記憶體空間，整個應用程式將受到影響，這將導致糟糕的使用者體驗。
Easy to Modify the Technology Stack
通過使用微服務，軟體開發公司可以在特定元件上嘗試新的堆疊或最新技術，以提高可用性，並在應用程式級別獲得更大的好處。由於不存在依賴問題，如果軟體開發人員沒有提供一致的使用者體驗，他們可以避免使用特定的技術棧。這樣持續的現代化，你的系統不會輕易過時。
Provides scalability 微服務對有效能問題的部件進行擴充套件，並使用最符合服務需求的硬體。由於每個服務都是單獨的元件，因此可以使用更多的容器部署可伸縮性，從而實現更有效的容量規劃、更少的許可成本和適當的硬體。關鍵服務的元件可以部署在多個伺服器上，以提高可用性和效能，而不會影響其他服務的效能。這種可伸縮性可以帶來更好的客戶體驗並節省成本。
Aligned With the Organization
如果一個組織正在使用微服務，那麼可以定義團隊規模來匹配所需的任務。此外，團隊可以被分成更小的小組，並且可以專注於應用程式的單個元件。由於最終目標是客戶滿意度和良好的使用者體驗，所以團隊不分為UI團隊、資料庫團隊等。例如，如果在UAE工作的團隊要處理3個服務，而在California工作的團隊要處理5個服務，那麼在California和UAE工作的每個團隊都可以獨立釋出和部署不同的功能。這些跨職能團隊致力於實現單一功能，打破團隊之間的隔閡，促進更好的協作。
Improved Productivity and Speed
有了微服務，生產率和速度可以很容易地解決。不同的團隊可以同時處理不同的元件，而不必等待一個團隊完成任務。這就加快了質量保證的速度，因為每個微服務都可以單獨測試。其他涉眾可以致力於增強已經開發的元件，而其他程式設計師則致力於其他元件。這提高了速度，並導致更快的產品釋出。
需要考慮的障礙
僅僅因為一切看起來都很華麗，並不意味著它對軟體行業來說是完美的;它確實有潛在的痛苦，這也需要解決:
由於微服務側重於分散式系統和獨立服務，每個請求都需要在模組之間小心處理。其中一個服務可能沒有響應，這迫使開發人員編寫額外的程式碼以避免中斷。
基於微服務的應用程式的測試可能是一項痛苦的任務，因為在開始測試之前需要確認每個依賴的服務。隨著服務數量的增加，複雜性不再停留在後臺!在所有服務上保留標籤變得不切實際，因為可能會出現資料庫錯誤、網路延遲、快取問題等。因此，彈性測試和錯誤注入成為了必須。
每個服務都依賴於它自己的API和平臺，跟蹤每一件事都是一項痛苦的工作。領導者需要監視多個實體並管理整個基礎設施，因為如果任何服務出現故障，跟蹤問題就變得很乏味。因此，健壯的監視是必要的。
隨著持續的交付和快速的發展，員工必須跟上敏捷性和速度要求利用微服務的好處。如果他們花很長一段時間提供伺服器，公司可能會陷入嚴重的麻煩。
微服務和整體架構之間區別
整個應用程式中的每個元件都必須很小，並且必須交付最終目標不同的技術可以用於不同的微服務
Microservices ArchitectureMonolithic Architecture 遵循所有業務目標的單層體系結構
Services are fastTakes more time即使一個服務宕機，也不會影響其他元件。其他服務可以繼續進行如果某一特定特性存在問題，則需要將整個系統拉下鬆散耦合和分散。所有獨立工作All services are tightly coupled更多的資源可以用來產生高收入由於服務不是孤立的，因此不可能進行更多的資源分配應用程式擴充套件是可能的;因此，硬體可以按照需求進行分配縮放有點困難;因此，硬體分配可能會造成浪費微型服務迅速發展，持續可用流程需要從頭開始;快速發展會變得困難通過定義良好的介面與其他微服務進行通訊Communication can be messed upFocuses on productFocuses on entire project最新的技術不能被使用，因為一個程式依賴於其他程式
微服務架構的未來
您可能已經清楚地瞭解了微服務體系結構及其改變軟體行業的潛力!隨著數字技術和多裝置支援的日益普及;軟體開發正在深入到複雜的過程中。但是軟體行業有幸擁有微服務體系結構，它可以作為解決軟體開發公司複雜性的完美解決方案。如果公司想採用它，它肯定會在技術和操作上影響企業文化。
大公司已經在使用中
今天，隨著微服務的興起，大多數公司都在推倒單體架構，採用現代架構來在激烈的競爭中發揮作用。其中包括Netflix、eBay、亞馬遜(Amazon)、Twitter、貝寶(PayPal)、沃爾瑪(Walmart)等等……
Netflix
NetFlix是最早在SOA體系結構中使用微服務的公司之一。在公司快速增長的時候，無法建立資料中心來提供可伸縮性。開發中的小問題需要軟體開發人員一次又一次地尋找問題。但是，當他們用微服務重構現有的架構時，他們每天能夠通過800種不同裝置的api處理10億個呼叫。如今，Netflix正在使用500+微服務和30+工程團隊。
優步
優步開始了它的微服務之旅，在一個城市建立的單一的單體架構。由於它只在一個城市執行，一個程式碼庫選項似乎是乾淨的選項，可以解決所有的業務問題。但是，當它迅速擴充套件到其他城市時，元件變得緊密耦合，封裝是另一個問題，而持續整合則是一個負擔。因此，為了解決所有這些複雜性，工程團隊重構了現有的應用程式並使用了微服務。
1.所有乘客和司機通過API閘道器連線
2.部署單獨的單元來執行單獨的功能
3.所有功能都可以單獨縮放
因此，從單體架構到微服務架構的轉變讓優步受益匪淺。
Amazon
亞馬遜是大型電子商務商店之一，它遵循單體的應用程式，使開發人員彼此分離，並將團隊從最終目標中分離出來。該公司必須解決協調過程之間的衝突，將它們合併為一個單獨的版本，並生成所有版本的主版本。需要重新執行全新的程式碼庫、測試用例，以確保沒有倉促的工作。這些小故障使得公司使用微服務架構!這個軟體解決方案通過自己的web服務api與世界進行通訊。因此，它非常成功。
做出選擇
無論你選擇是整體服務還是微服務，兩者都有其優點和缺點。最後，選擇軟體架構取決於您的專案需求、專案的大小等等。如果您希望構建小型軟體，那麼單體架構是一種選擇，如果您喜歡開發複雜的軟體，那麼微服務體系結構無疑是一個很好的選擇。
