上篇文章給大家簡單介紹了一下微處理架構，現在我來為大家分析微服務架構的優勢與不足。
微處理架構——處理複雜事物
許多公司，比如amazon、ebay和netflix，通過採用微處理結構模式解決了上述問題。其思路不是開發乙個巨大的單體式的應用，而是將應用分解為小的、互相連線的微服務。
乙個微服務一般完成某個特定的功能，比如下單管理、客戶管理等等。每乙個微服務都是微型六角形應用，都有自己的業務邏輯和介面卡。一些微服務還 會發布api給其它微服務和應用客戶端使用。其它微服務完成乙個web ui，執行時，每乙個例項可能是乙個雲vm或者是docker容器。
比如，乙個前面描述系統可能的分解如下：
每乙個應用功能區都使用微服務完成，另外，web應用會被拆分成一系列簡單的web應用（比如乙個對乘客，乙個對計程車駕駛員）。這樣的拆分對於不同使用者、裝置和特殊應用場景部署都更容易。
每乙個後台服務開放乙個rest api，許多服務本身也採用了其它服務提供的api。比如，駕駛員管理使用了告知駕駛員乙個潛在需求的通知服務。ui服務啟用其它服務來更新web頁面。所有服務都是採用非同步的，基於訊息的通訊。微服務內部機制將會在後續系列中討論。
一些rest api也對乘客和駕駛員採用的移動應用開放。這些應用並不直接訪問後台服務，而是通過api gateway來傳遞中間訊息。api gateway負責負載均衡、快取、訪問控制、api 計費監控等等任務，可以通過nginx方便實現，後續文章將會介紹到api gateway。
·微服務架構模式在上圖中對應於代表可擴充套件scale cube的y軸，這是乙個在《the art of scalability》書中描述過的三維擴充套件模型。另外兩個可擴充套件軸，x軸由負載均衡器後端執行的多個應用副本組成，z軸是將需求路由到相關服務。
應用基本可以用以上三個維度來表示，y軸代表將應用分解為微服務。執行時，x軸代表執行多個隱藏在負載均衡器之後的例項，提供吞吐能力。一些應用可能還是用z軸將服務分割槽。下面的圖演示行程管理服務如何部署在執行於aws ec2上的docker上。
執行時，行程管理服務由多個服務例項構成。每乙個服務例項都是乙個docker容器。為了保證高可用，這些容器一般都執行在多個雲vm上。服務例項前是 一層諸如nginx的負載均衡器，他們負責在各個例項間分發請求。負載均衡器也同時處理其它請求，例如快取、許可權控制、api統計和監控。
這種微服務架構模式深刻影響了應用和資料庫之間的關係，不像傳統多個服務共享乙個資料庫，微服務架構每個服務都有自己的資料庫。另外，這種思路也影響到了企業級資料模式。同時，這種模式意味著多份資料，但是，如果你想獲得微服務帶來的好處，每個服務獨有乙個資料庫是必須的，因為這種架構需要這種松耦合。下面的圖演示示例應用資料庫架構。
每種服務都有自己的資料庫，另外，每種服務可以用更適合自己的資料庫型別，也被稱作多語言一致性架構。比如，駕駛員管理（發現哪個駕駛員更靠近乘客），必須使用支援地理資訊查詢的資料庫。
表面上看來，微服務架構模式有點像soa，他們都由多個服務構成。但是，可以從另外乙個角度看此問題，微服務架構模式是乙個不包含web服務 （ws-）和esb服務的soa。微服務應用樂於採用簡單輕量級協議，比如rest，而不是ws-，在微服務內部避免使用esb以及esb類似功能。微服 務架構模式也拒絕使用canonical schema等soa概念。
微服務架構的好處
微服務架構模式有很多好處。首先，通過分解巨大單體式應用為多個服務方法解決了複雜性問題。在功能不變的情況下，應用被分解為多個可管理的分支 或服務。每個服務都有乙個用rpc-或者訊息驅動api定義清楚的邊界。微服務架構模式給採用單體式編碼方式很難實現的功能提供了模組化的解決方案，由 此，單個服務很容易開發、理解和維護。
第二，這種架構使得每個服務都可以有專門開發團隊來開發。開發者可以自由選擇開發技術，提供api服務。當然，許多公司試圖避免混亂，只提供某 些技術選擇。然後，這種自由意味著開發者不需要被迫使用某專案開始時採用的過時技術，他們可以選擇現在的技術。甚至於，因為服務都是相對簡單，即使用現在 技術重寫以前**也不是很困難的事情。
第三，微服務架構模式是每個微服務獨立的部署。開發者不再需要協調其它服務部署對本服務的影響。這種改變可以加快部署速度。ui團隊可以採用ab測試，快速的部署變化。微服務架構模式使得持續化部署成為可能。
最後，微服務架構模式使得每個服務獨立擴充套件。你可以根據每個服務的規模來部署滿足需求的規模。甚至於，你可以使用更適合於服務資源需求的硬體。 比如，你可以在ec2 compute optimized instances上部署cpu敏感的服務，而在ec2 memory-optimized instances上部署記憶體資料庫。
微服務架構的不足
fred brooks在30year前寫道，「there are no silver bullets」，像任何其它科技一樣，微服務架構也有不足。其中乙個跟他的名字類似，『微服務』強調了服務大小，實際上，有一些開發者鼓吹建立稍微大一 些的，10-100 loc服務組。儘管小服務更樂於被採用，但是不要忘了這只是終端的選擇而不是最終的目的。微服務的目的是有效的拆分應用，實現敏捷開發和部署。
另外乙個主要的不足是，微服務應用是分布式系統，由此會帶來固有的複雜性。開發者需要在rpc或者訊息傳遞之間選擇並完成程序間通訊機制。更甚 於，他們必須寫**來處理訊息傳遞中速度過慢或者不可用等區域性失效問題。當然這並不是什麼難事，但相對於單體式應用中通過語言層級的方法或者程序呼叫，微 服務下這種技術顯得更複雜一些。
另外乙個關於微服務的挑戰來自於分割槽的資料庫架構。商業交易中同時給多個業務分主體更新訊息很普遍。這種交易對於單體式應用來說很容易，因為只 有乙個資料庫。在微服務架構應用中，需要更新不同服務所使用的不同的資料庫。使用分布式交易並不一定是好的選擇，不僅僅是因為cap理論，還因為今天高擴 展性的nosql資料庫和訊息傳遞中介軟體並不支援這一需求。最終你不得不使用乙個最終一致性的方法，從而對開發者提出了更高的要求和挑戰。
測試乙個基於微服務架構的應用也是很複雜的任務。比如，採用流行的spring boot架構，對乙個單體式web應用，測試它的rest api，是很容易的事情。反過來，同樣的服務測試需要啟動和它有關的所有服務（至少需要這些服務的stubs）。再重申一次，不能低估了採用微服務架構帶 來的複雜性。
另外乙個挑戰在於，微服務架構模式應用的改變將會波及多個服務。比如，假設你在完成乙個案例，需要修改服務a、b、c，而a依賴b，b依賴c。 在單體式應用中，你只需要改變相關模組，整合變化，部署就好了。對比之下，微服務架構模式就需要考慮相關改變對不同服務的影響。比如，你需要更新服務c， 然後是b，最後才是a，幸運的是，許多改變一般只影響乙個服務，而需要協調多服務的改變很少。
部署乙個微服務應用也很複雜，乙個分布式應用只需要簡單在複雜均衡器後面部署各自的伺服器就好了。每個應用例項是需要配置諸如資料庫和訊息中介軟體等基礎服務。相對比，乙個微服務應用一般由大批服務構成。例如，根據adrian cockcroft，netflix 有大約600個服務。每個服務都有多個例項。這就造成許多需要配置、部署、擴充套件和監控的部分，除此之外，你還需要完成乙個服務發現機制（後續文章中發 表），以用來發現與它通訊服務的位址（包括伺服器位址和埠）。傳統的解決問題辦法不能用於解決這麼複雜的問題。接續而來，成功部署乙個微服務應用需要開 發者有足夠的控制部署方法，並高度自動化。
一種自動化方法是使用paas服務，例如cloud foundry。 paas給開發者提供乙個部署和管理微服務的簡單方法，它把所有這些問題都打包內建解決了。同時，配置paas的系統和網路專家可以採用最佳實踐和策略來 簡化這些問題。另外乙個自動部署微服務應用的方法是開發對於你來說最基礎的paas系統。乙個典型的開始點是使用乙個集群化方案，比如配合docker使 用mesos或者kubernetes。後面的系列我們會看看如何基於軟體部署方法例如nginx，可以方便的在微服務層面提供快取、許可權控制、api統 計和監控。
總結構建複雜的應用真的是非常困難。單體式的架構更適合輕量級的簡單應用。如果你用它來開發複雜應用，那真的會很糟糕。微服務架構模式可以用來構建複雜應用，當然，這種架構模型也有自己的缺點和挑戰。
在後續的部落格中，我會深入探索微服務架構模式，並討論諸如服務發現、服務部署選擇和如何分解乙個分布式應用為多個服務的策略。
微服務架構的優勢與不足（二）
微處理架構 處理複雜事物 許多公司，比如amazon ebay和netflix，通過採用微處理結構模式解決了上述問題。其思路不是開發乙個巨大的單體式的應用，而是將應用分解為小的 互相連線的微服務。乙個微服務一般完成某個特定的功能，比如下單管理 客戶管理等等。每乙個微服務都是微型六角形應用，都有自己的...
微服務架構優勢
複雜度可控 在將應用分解的同時，規避了原本複雜度無止境的積累。每乙個微服務專注於單一功能，並通過定義良好的介面清晰表述服務邊界。由於體積小 複雜度低，每個微服務可由乙個小規模開發團隊完全掌控，易於保持高可維護性和開發效率。獨立部署 由於微服務具備獨立的執行程序，所以每個微服務也可以獨立部署。當某個微...
微服務架構的優勢
微服務可通過分布式部署，大幅提公升您的團隊和日常工作效率。您還可以並行開發多個微服務。這意味著更多開發人員可以同時開發同乙個應用，進而縮短開發所需的時間。由於開發周期縮短，微服務架構有助於實現更加敏捷的部署和更新。隨著某些服務的不斷擴充套件，您可以跨多個伺服器和基礎架構進行部署，充分滿足自身需求。只...