2017年 src 角色 後臺 get 如果 大數據分析 str 中心

目前用的較多的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的業務，因而累積了大量的用戶數據，公司的運營需要通過這部分數據進行大數據分析和數字化運營，因而在這些企業裏面往往還需要關註數據架構。

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

2018第47周日