2018第47週日

 

目前用的較多的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的業務，於是累積了大量的用戶數據，公司的運營須要經過這部分數據進行大數據分析和數字化運營，於是在這些企業裏面每每還須要關注數據架構。 從事互聯網應用的企業，每每首先關注的是應用架構，是否可以知足終端客戶的需求，帶給客戶良好的用戶體驗，業務量每每會在短時間內出現爆炸式的增加，於是關注高併發應用架構，並但願這個架構能夠快速迭代，從而搶佔風口。