作為流行的微服務框架，Spring Could實用但不完美，比如說它只針對Java語言，堅持REST協議做微服務間的通訊等。
Spring Cloud雖然集成了眾多組件，可以構建一個完整的微服務應用，但是其中的各個組件卻並非完美無缺，很多組件在實際應用中都存在諸多不足和缺陷。因此，需要我們對其中的一些組件進行替換和修改，方能構建一個強大、靈活、健壯的微服務架構應用。
配置中心
Spring Cloud Config可以說是Spring Cloud家族中實現最Low的一個組件，直接采用了本地存儲/SVN/Git的方式進行存儲。同時，Spring Cloud Config也缺乏一個完整的可視化管理查詢后台，當存在比較復雜的權限管理和版本管理需求時，Spring Cloud Config會顯得非常力不從心。如果需要在配置修改后，能自動進行配置信息推送的話，使用Spring Cloud Config也無法滿足要求，需要自行編寫代碼進行實現。
目前開源社區中，已經有了很多的開源配置中心實現方案，同時很多公司也自研了自己的配置中心方案。包括淘寶的統一配置中心Diamond（已經多年未更新）、百度的分布式配置管理平台Disconf、攜程的開源分布式配置中心Apollo、360的分布式配置管理工具QConf等等。
注冊中心
作為Spring Cloud的服務注冊中心，從分布式CAP理論來看，Eureka采用是AP型設計，強調的是注冊中心的高可用性。和Dubbo常用的服務注冊中心ZooKeeper相比，ZooKeeper則是采用的CP型設計，強調的是注冊中心數據的一致性。
Eureka的設計確實簡單易用，但是默認沒有實現對注冊中心數據的持久化。同時，在極端場景下，也會出現多個Eureka注冊中心節點數據不一致，甚至服務注冊數據丟失的情況。當然，從分布式CAP理論來看，理論上是沒辦法做到同時兼顧CAP三點的。目前也有一些互聯網公司對Eureka進行了改造，支持了數據的持久化，但是尚不能完整的支持CAP的全部要求。
API網關
API網關可以說是微服務需求最多，也是最有難點的一個組件。Spring Cloud中集成的Zuul應該說更多的是實現了服務的路由功能，對於負載均衡等其他功能，需要結合Ribbon等組件來實現。對於很多個性化的需求，需要開發者自己來進行編碼實現。
和大部分基於Java的Web應用類似，Zuul也采用了Servlet架構，因此Zuul處理每個請求的方式是針對每個請求是用一個線程來處理。同時，由於Zuul是基於JVM的實現，因此性能也會在高並發訪問場景下成為瓶頸。雖然網上一些文章評測Zuul和Nginx性能接近，但是在性能要求較高的場景下，JVM的內存管理和垃圾回收問題，仍然是一個很大的問題。所以在實際的應用場景中，通常會采用在多個Zuul幾點前面再添加一層Nginx或者OpenResty來進行代理。
為了解決Zuul的性能問題，Netflix將自己的網關服務Zuul進行了升級，新的Zuul 2將HTTP請求的處理方式從同步變成了異步，並且新增諸如HTTP/2、websocket等功能。但是遺憾的是，開源版本的Zuul 2一直處於難產狀態中，始終沒有和大家正式見面。
熔斷器
微服務中對於服務的限流、降級、熔斷的需求是多種多樣的，需要在API網關和各個具體服務接口中分別進行控制，才能滿足復雜場景下微服務架構的應用需求。
單獨使用Spring Cloud中的Hystrix無法完整的滿足上述的復雜需求，需要結合API網關，並通過Kubernetes對資源、進程和命名空間來提供隔離，並通過部分自定義編碼方能實現對全部服務的限流、降級、熔斷等需求。
監控系統
無論是Spring Cloud中集成的Spring Cloud Sleuth，還是集成經典的ELK，都只是對日志級別的追蹤和監控。在大中型微服務應用架構中，尤其是基於JVM的項目，還需要添加APM的監控機制，才能保證及時發現各種潛在的性能問題。
APM整體上主要完成3點功能：1.日志追蹤、2.監控報警、3.性能統計。目前，國內外商業版本的APM方案已經有很多，開源版本的APM方案也開始豐富起來。國內開源的APM方案主要有：大眾點評的CAT和Apache孵化中的SkyWalking。這里給大家重點推薦下SkyWalking，SkyWalking是針對分布式系統的應用性能監控系統，特別針對微服務、Cloud Native和容器化（Docker、Kubernetes、Mesos）架構，項目的關注度和發展速度都很快，中文文檔資料也比較齊全。