“微服務架構提供了一系列技術優勢，有助於提高軟體專案的開發速度和產品質量，同時也有助於提高整體業務靈活性” - MARK EMEIS，軟體技術高階總監，CA技術

自從該術語成立以來，微服務一直在軟體開發中獲得成功。微服務（又稱微服務架構）是面向服務的體系結構（SOA）的變體，用於開發大型應用程式，其中服務按照業務域分為多個塊。它提供了複雜應用程式的持續交付/部署，使應用程式更易於理解，開發，測試，並且對架構侵蝕更具彈性。微服務架構提供了一種以新穎方式編織現有系統的新方法，以便快速提供軟體解決方案。由於其提供模組化，可擴充套件性，可用性的能力，成為軟體行業最熱門的話題之一；許多企業軟體開發公司都熱衷於採用它。

但是，微服務究竟是什麼？它能改善組織的文化，技能和需求嗎？

為了深入理解微服務，讓我們首先理解相反方法單片架構的要點。

關於單體軟體的一切

維基百科說：“單片應用程式描述了一個單層軟體應用程式，其中使用者介面和資料訪問程式碼從單一平臺組合成一個程式。”

單片軟體使用三層架構，即

表示層 - 它是應用程式的最頂層，描述了使用者介面。主要功能是將任務和結果轉換為使用者可以理解的內容。使用者介面程式碼使用HTML，JavaScript和CSS等客戶端技術編寫。

業務層 - 該層做出邏輯決策並執行計算。它處理兩層之間的資料，並使用像Spring這樣的技術。

資料訪問層 - 這裡儲存資訊並從資料庫中檢索資訊。資訊將傳遞到業務層，最終傳遞給使用者。它使用像Hibernate這樣的ORM工具來處理資訊。

這裡，Web應用程式客戶端傳送請求；層執行業務邏輯，資料庫儲存應用程式特定資料，UI將特定資料顯示給使用者。但是，由於它們共享相同的程式碼庫，因此可能會出現一些問題。

這種型別的架構在一段時間內執行良好，但由於對持續交付的需求不斷增加，此模型存在多個問題。

單片架構的缺點

運維開銷：不同的利益相關者使用不同的單一應用層；因此團隊將被限制在特定領域的專業知識。在表示層工作的團隊專注於UI技術，但對資料訪問層的瞭解最少。因此，如果要新增新功能，則需要不同的團隊來協調和傳遞特定功能。這導致從構思到上市時間的更長時間跨度，並最終影響業務ROI。

軟體堆疊自治：它限制了技術選擇並迫使整個層使用單一框架。例如，如果表示層是在HTML框架中編寫的，則整個層將在同一框架內實現。這避免了實施最新技術，導致應用程式程式碼在短時間內過時。

隱式介面：由於此程式碼在單個檔案中釋出，因此應用程式中的微小更改會要求重建整個應用程式。因此，正在進行的應用程式被放下並導致需要重新部署新版本。這種性質導致更新更少，並且無法儘可能快地發展。

可擴充套件性：單片應用程式具有一維可擴充套件性；因此無法擴充套件單個元件。因此，即使大多數應用程式可能不需要擴充套件，也需要擴充套件整個應用程式。

開發沒有良好架構的軟體會給組織帶來很大的成本。例如：如果軟體開發公司透過遵循非模組化方法開發軟體，其中UI功能和業務功能混合在相同的原始檔中，公司可能需要投入大量資金來支援他們在最新智慧手機本機中的應用程式應用。這嚴重影響了軟體的可維護性並延長了產品上市時間，最終影響了公司的銷售。

單片體系結構一直是傳統方法，但是擴充套件的限制，維護大型程式碼庫的困難，高風險升級以及大量的前期設定成本迫使企業或軟體開發公司探索不同的方法。單片應用程式是一個難以破解的難題，難以理解並隨著時間的推移而擴充套件。

因此，為了避免這些問題，微服務架構可以成為一個救星！它提供360度扭曲以解決上述複雜問題；幫助軟體開發公司在競爭對手中脫穎而出。

微服務架構簡介

微服務是一種軟體開發技術，它將應用程式構建為鬆散耦合服務的集合。每項服務都是獨立的，應該實現單一的業務能力。微服務架構旨在克服較大應用程式的挑戰，故障和故障。微服務提供了為系統增加彈性的機會，以便元件可以優雅地處理峰值和錯誤。有了這個，每個利益相關者都可以專注於整個應用程式的一個特定元素，具有自己的程式設計風格，而不用擔心其他元件。微服務中的通訊可以毫不費力地執行，因為它們是無狀態的並且在明確定義的介面中（請求和響應是獨立的）。

如果使用微服務方法開發應用程式/軟體，將有助於採用DevOps方法，並將消除部署效率低下，從而縮短產品上市時間。由於微服務與裝置和平臺無關，因此可以開發應用程式，在大多數平臺上提供增強的使用者體驗，包括Web，移動，物聯網，平板電腦，可穿戴裝置等等。

例如：沃爾瑪加拿大在2012年之前使用了單片架構！該公司在處理600萬頁面瀏覽量/分鐘時遇到了麻煩，這耗費了更多時間並導致銷售額減少。由於這些問題，他們將自己的軟體架構重構為微服務，並在一夜之間找到了即時結果和高轉換率。停機時間最小化，公司能夠使用更便宜的x86伺服器而不是昂貴的硬體商品，從而節省了20％-50％的成本。

微服務和SOA

這是SOA的自然演變，其中各種技術堆疊將技術多樣性帶入開發團隊。 SOA和微服務都允許將複雜的工作負載分解為更小，更易於管理和獨立的部分。

但是，它們之間存在一些基本差異。

微服務與SOA

微服務哲學

微服務的哲學類似於Unix哲學，即“做一件事，做得好”。特徵描述如下……

用於執行單一功能的元件化

按業務能力組織

專注於不加工的產品

分散治理和資料管理

服務具有彈性，彈性，可組合性，最小化和完整性

軟體開發公司為什麼要投資微服務架構？

改善了故障隔離

在微服務架構中，開發人員確切地知道在哪裡尋找要解決的問題。如果單個模組受到影響，則可以輕鬆拆卸或解決，而不會影響應用程式的其他部分；提高應用程式的可用性。這在整體應用中完全矛盾；單個元件的故障可以拉低整個應用程式。例如，移動遊戲應用程式（基於單片架構），具有不同的元件，如支付，登入，播放器，歷史記錄等。如果特定元件開始佔用更多記憶體空間，整個應用程式將受到影響，這將導致糟糕的使用者體驗。

易於修改技術堆疊

透過微服務，軟體開發公司可以在特定元件上嘗試新的堆疊或最新技術，以提高可用性並在應用程式級別獲得更大的好處。由於沒有依賴性問題，軟體開發人員可以避免使用特定的技術堆疊，如果他們不提供一致的使用者體驗。透過這種持續的現代化，您的系統不會變得容易過時。

提供可擴充套件性

微服務可擴充套件存在效能問題的部件，並使用最符合服務要求的硬體。由於每個服務都是獨立的元件，因此可以使用更多容器部署擴充套件，從而實現更有效的容量規劃，更少的許可成本和適當的硬體。關鍵服務的元件可以部署在多個伺服器上，以提高可用性和效能，而不會影響其他服務的效能。這種可擴充套件性可帶來更好的客戶體驗並增加成本節約。

與該組織保持一致

如果組織使用微服務，則可以定義團隊規模以匹配所需任務。此外，團隊可以分解為更小的組，並可以專注於應用程式的單個元件。由於最終目標是客戶滿意度和良好的使用者體驗，團隊不分為UI團隊，資料庫團隊等。例如，如果在阿聯酋工作的團隊正在處理三項服務，而在加利福尼亞工作的團隊正在處理五項服務，那麼在加利福尼亞和阿聯酋工作的每個團隊都可以獨立釋出和部署不同的功能。這些跨職能團隊致力於實現單一功能，打破團隊之間的孤島，促進更好的協作。

提高生產力和速度

透過微服務，可以輕鬆解決生產率和速度問題。不同的團隊同時處理不同的元件，而無需等待一個團隊完成任務。這樣可以加快質量保證，因為每個微服務都可以單獨測試。其他利益相關者可以致力於增強已經開發的元件，而其他程式設計師則在開發其他程式設計師。這樣可以提高速度並加快產品的釋出速度。

需要考慮的障礙……

僅僅因為，一切看起來都很華麗，並不意味著它對軟體行業來說是完美的；它確實有潛在的痛苦，也需要解決： -

由於微服務側重於分散式系統和獨立服務，因此需要在模組之間仔細處理每個請求。可能會發生其中一個服務沒有響應，迫使開發人員編寫額外的程式碼以避免中斷。

基於微服務的應用程式的測試可能是一項痛苦的任務，因為在開始測試之前需要確認每個依賴服務。隨著服務數量的增加，複雜性不會留在後臺！密切關注所有服務變得不切實際，因為可能會出現資料庫錯誤，網路延遲，快取問題等。因此，彈性測試和故障注入成為必須。

每項服務都依賴於自己的API和平臺，追蹤所有內容都可能是一項痛苦的堆疊工作。領導者需要監控多個實體並管理整個基礎架構，因為如果在任何情況下任何服務都失敗，追蹤問題就變得很繁瑣。因此，強有力的監測變得必要。

隨著持續交付和快速發展，員工必須提高靈活性和速度，這需要利用微服務帶來的好處。如果他們花費很長時間來配置伺服器，公司可能會遇到嚴重問題。

單體架構和微服務架構的區別

微服務架構的未來

您可能已經清楚瞭解微服務架構及其改變軟體行業所具有的潛力！隨著數字技術的使用越來越多，裝置支援越來越多；軟體開發正在深入到複雜的過程中。但軟體行業擁有微服務架構，可以作為解決軟體開發公司複雜性的完美解決方案。如果公司考慮採用它，它肯定會在技術和操作上影響文化。

Big Giants已經在使用它......

今天，隨著微服務的興起，大多陣列織正在拉低整體架構並採用現代架構來利用激烈的競爭。其中一些包括Netflix，eBay，亞馬遜，Twitter，PayPal，沃爾瑪等等……

讓我們看看NetFlix如何解決......

NetFlix：NetFlix是最早在SOA架構中使用微服務的採用者之一。公司快速發展的時候，無法建立資料中心來提供可擴充套件性。開發中的一些小問題需要軟體開發人員一次又一次地查詢問題。但是，當他們使用微服務重構現有架構時，他們每天能夠透過800個不同裝置的API處理十億次呼叫。如今，Netflix正在使用500多個微服務和30多個工程團隊。

優步：優步以單一建築為單一城市的單一建築開始了它的旅程。由於它只在一個城市運營，因此一個程式碼庫選項似乎是一個乾淨的選擇並解決了所有業務問題。但是，當它迅速擴充套件到其他城市時，元件變得緊密耦合，封裝是另一個問題，持續整合變成了一種負擔。因此，為了解決所有這些複雜問題，工程團隊重構了現有的應用程式並使用了微服務。他們介紹了

所有乘客和司機都透過的API閘道器

部署單獨的單元以執行單獨的功能

所有功能都可以單獨縮放

因此，優步透過從單片架構轉向微服務架構而獲益匪淺。

亞馬遜：亞馬遜是大型電子商務商店之一，緊隨其後的是整體應用程式，它使開發人員彼此分開，並將團隊與最終目標區分開來。該公司必須解決協調過程之間的衝突，將它們合併為一個版本並生成所有版本的主版本。需要重新執行全新的基於程式碼的測試用例，以確保沒有任何衝動。這些故障使公司使用微服務架構！該軟體解決方案透過自己的Web服務API與全世界進行通訊。因此，它非常成功。

做出選擇

無論選擇哪種軟體解決方案，無論是單片還是微服務，都有它們各有優缺點。最後，選擇軟體架構取決於您的專案要求，專案規模等等。如果您希望構建小型軟體，微控制器可以作為一種選擇，如果您更喜歡開發複雜的軟體，那麼微服務架構肯定是一個肯定的鏡頭。

仍然不清楚您的要求或希望為您的下一個大專案重構現有的軟體架構？請聯絡我們，我們的技術顧問會回覆您解決您的疑問！

請關注公眾號：【首席架構師智庫】

討論：請加入知識星球【首席架構師圈】或者小號【jiagoushi_pro】或者QQ群【11107777】