目前用的較多的Spring Could是註冊中心consul，它通過叢集設計、raft選舉演算法，gossip協議等機制確保consul服務的高可用，若有更高的容災機制，則要異地多資料中心設計。

Spring Could Config中心也是一個重要的獨立元件，所有的微服務應用都要調它獲取配置資訊。

Spring Could中微服務間呼叫負載均衡、服務熔斷、限流等機制是都是在服務消費端實現，對消費端程式碼有一定的侵入性，這與Service Mesh的Proxy模式不同。

---

 

當然，Spring Could 元件也有不少不支援的功能：

Spring Could Config沒有視覺化管理後臺，不支援複雜的許可權和版本管理，配置修改後無法自動進行配置資訊的推送。

Spring Could預設註冊中心Erueka是AP型設計，強調高可用性，極端情況下可能出現多個註冊中心節點不一致，甚至註冊資料丟失情況。

Spring Could整合的閘道器Zuul負載均衡功能需要結合Ribbon實現，它用Servlet架構，基於JVM實現，高併發下效能會成為瓶頸。

Spring Could Hystrix無法實現對API閘道器各個具體服務介面分別捷星限流、降級、熔斷的控制需求。

Spring Could Sleuth整合經典的ELK知識對日誌級別做跟蹤和監控，實際專案還需要APM的監控機制。

---

 

Spring Could微服務對程式碼有一定的入侵性，如果是老專案沒辦法升級用Spring boot框架開發的話，你可以考慮ServiceMesh。

通過Spring Cloud、Docker和Kubernetes的組合，可以構建更加完整和強大的微服務架構程式。通過三者的整合，使用Spring Boot提供應用的打包，Docker和Kubernetes提供應用的部署和排程。Spring Cloud通過Hystrix執行緒池提供應用內的隔離，而Kubernetes通過資源、程序和名稱空間來提供隔離。Spring Cloud為每個微服務提供健康終端，而Kubernetes執行健康檢查，且把流量導到健康服務。Spring Cloud外部化配置並更新它們，而Kubernetes分發配置到每個微服務。

基於Spring Could實現的微服有務技術門檻高，多語言支援不足，對業務程式碼有一定的侵入性，技術升級切換成本高的問題，於是有人開始嘗試用Servie Mesh來解決。 微服務的概念在2014年3月由Martin Fowler首次提出，而Service Mesh的概念則是在2016年左右提出，Service Mesh至今也經歷了第二代的發展。直到2017年年底，當非侵入式的Service Mesh技術終於從萌芽到走向了成熟，當Istio/Conduit橫空出世，人們才驚覺：微服務並非只有侵入式一種玩法，更不是Spring Cloud的獨角戲！

 

企業上的三大架構為IT架構，應用架構和資料架構，在不同的公司，不同的人，不同的角色，關注的重點不同。

對於大部分的企業來講，上雲的訴求是從IT部門發起的，發起人往往是運維部門，他們關注計算，網路，儲存，試圖通過雲端計算服務來減輕CAPEX和OPEX。

有的公司有ToC的業務，因而累積了大量的使用者資料，公司的運營需要通過這部分資料進行大資料分析和數字化運營，因而在這些企業裡面往往還需要關注資料架構。

從事網際網路應用的企業，往往首先關注的是應用架構，是否能夠滿足終端客戶的需求，帶給客戶良好的使用者體驗，業務量往往會在短期內出現爆炸式的增長，因而關注高併發應用架構，並希望這個架構可以快速迭代，從而搶佔風口。