微服務架構，同其它科技發展一樣，目前的階段也不完善。中培偉業《微服務架構設計與最佳實踐》專家龔老師指出，微服務強調了服務大小，實際上，有一些開發者鼓吹建立稍微大一些的，10-100 LOC服務組。盡管小服務更樂于被采用，但是不要忘了這只是終端的選擇而不是最終的目的。微服務的目的是有效的拆分應用，實現敏捷開發和部署。

另外一個主要的不足是，微服務應用是分布式系統，由此會帶來固有的復雜性。開發者需要在RPC或者消息傳遞之間選擇并完成進程間通訊機制。更甚于，他們必須寫代碼來處理消息傳遞中速度過慢或者不可用等局部失效問題。當然這并不是什么難事，但相對于單體式應用中通過語言層級的方法或者進程調用，微服務下這種技術顯得更復雜一些。

另外一個關于微服務的挑戰來自于分區的數據庫架構。商業交易中同時給多個業務分主體更新消息很普遍。這種交易對于單體式應用來說很容易，因為只有一個數據庫。在微服務架構應用中，需要更新不同服務所使用的不同的數據庫。使用分布式交易并不一定是好的選擇，不僅僅是因為CAP理論，還因為今天高擴展性的NoSQL數據庫和消息傳遞中間件并不支持這一需求。最終你不得不使用一個最終一致性的方法，從而對開發者提出了更高的要求和挑戰。

測試一個基于微服務架構的應用也是很復雜的任務。比如，采用流行的Spring Boot架構，對一個單體式web應用，測試它的REST API，是很容易的事情。反過來，同樣的服務測試需要啟動和它有關的所有服務（至少需要這些服務的stubs）。再重申一次，不能低估了采用微服務架構帶來的復雜性。

另外一個挑戰在于，微服務架構模式應用的改變將會波及多個服務。部署一個微服務應用也很復雜，一個分布式應用只需要簡單在復雜均衡器后面部署各自的服務器就好了。每個應用實例是需要配置諸如數據庫和消息中間件等基礎服務。相對比，一個微服務應用一般由大批服務構成。例如，根據Adrian Cockcroft，Hailo有160個不同服務構成，NetFlix有大約600個服務。每個服務都有多個實例。這就造成許多需要配置、部署、擴展和監控的部分，除此之外，你還需要完成一個服務發現機制（后續文章中發表），以用來發現與它通訊服務的地址（包括服務器地址和端口）。傳統的解決問題辦法不能用于解決這么復雜的問題。接續而來，成功部署一個微服務應用需要開發者有足夠的控制部署方法，并高度自動化。

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

不過盡管面臨很多挑戰，龔老師對微服務的未來的發展依然充滿信心，他認為這就像任何其他新興科技一樣，其發展必然會經歷一個從不足到不斷完善的發展階段。