微服務架構的好處

　　微服務架構模式有很多好處。首先，通過分解巨大單體式應用為多個服務方法解決了複雜性問題。在功能不變的情況下，應用被分解為多個可管理的分支或服務。每個服務都有一個用RPC-或者訊息驅動API定義清楚的邊界。微服務架構模式給採用單體式編碼方式很難實現的功能提供了模組化的解決方案，由此，單個服務很容易開發、理解和維護。

　　第二，這種架構使得每個服務都可以有專門開發團隊來開發。開發者可以自由選擇開發技術，提供API服務。當然，許多公司試圖避免混亂，只提供某些技術選擇。然後，這種自由意味著開發者不需要被迫使用某專案開始時採用的過時技術，他們可以選擇現在的技術。甚至於，因為服務都是相對簡單，即使用現在技術重寫以前程式碼也不是很困難的事情。

　　第三，微服務架構模式是每個微服務獨立的部署。開發者不再需要協調其它服務部署對本服務的影響。這種改變可以加快部署速度。UI團隊可以採用AB測試，快速的部署變化。微服務架構模式使得持續化部署成為可能。

　　最後，微服務架構模式使得每個服務獨立擴充套件。你可以根據每個服務的規模來部署滿足需求的規模。甚至於，你可以使用更適合於服務資源需求的硬體。比如，你可以在EC2 Compute Optimized instances上部署CPU敏感的服務，而在EC2 memory-optimized instances上部署記憶體資料庫。

　　微服務架構的不足

　　Fred Brooks在30年前寫道，“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，Hailo有160個不同服務構成，NetFlix有大約600個服務。每個服務都有多個例項。這就造成許多需要配置、部署、擴充套件和監控的部分，除此之外，你還需要完成一個服務發現機制（後續文章中發表），以用來發現與它通訊服務的地址（包括伺服器地址和埠）。傳統的解決問題辦法不能用於解決這麼複雜的問題。接續而來，成功部署一個微服務應用需要開發者有足夠的控制部署方法，並高度自動化。

　　一種自動化方法是使用PaaS服務，例如Cloud Foundry。PaaS給開發者提供一個部署和管理微服務的簡單方法，它把所有這些問題都打包內建解決了。同時，配置PaaS的系統和網路專家可以採用最佳實踐和策略來簡化這些問題。另外一個自動部署微服務應用的方法是開發對於你來說最基礎的PaaS系統。一個典型的開始點是使用一個叢集化方案，比如配合Docker使用Mesos或者Kubernetes。後面的系列我們會看看如何基於軟體部署方法例如NGINX，可以方便的在微服務層面提供快取、許可權控制、API統計和監控。

　　總結

　　構建複雜的應用真的是非常困難。單體式的架構更適合輕量級的簡單應用。如果你用它來開發複雜應用，那真的會很糟糕。微服務架構模式可以用來構建複雜應用，當然，這種架構模型也有自己的缺點和挑戰。

　　在後續的部落格中，我會深入探索微服務架構模式，並討論諸如服務發現、服務部署選擇和如何分解一個分散式應用為多個服務的策略。