靈活高性能的RPC實現(xiàn)。Java Chassis基于Open API，給出了不同RPC開發(fā)方式的統(tǒng)一描述，讓微服務接口管理更加規(guī)范，同時保留了靈活的開發(fā)者使用習慣。Java Chassis基于Reactive，實現(xiàn)了高效的REST、Highway等通信協(xié)議，同時保留了傳統(tǒng)Servlet等通信協(xié)議的兼容。

豐富的服務治理能力和統(tǒng)一的治理職責鏈。負載均衡、流量控制、故障隔離等常見的微服務治理能力都可以開箱即用，同時提供了統(tǒng)一的治理職責鏈，讓新的治理功能的開發(fā)變得簡單。

和Spring Cloud一樣，Java Chassis也可以使用Spring、Spring Boot作為應用功能開發(fā)的基礎組件，但是由于Java Chassis提供了獨立的RPC實現(xiàn)，因此使用依賴于Spring MVC的功能組件會受到限制，比如使用Spring Securtiy，需要基于Java Chassis做一些適配。

ava Chassis提供了豐富的組件，幫助搭建具備足夠韌性的云原生系統(tǒng)。Edge Service具備通用網(wǎng)關的大部分能力，并且集成了Java Chassis的服務治理能力，可以實現(xiàn)Java Chassis多協(xié)議轉發(fā)。

該架構采用靜態(tài)頁面和服務分離，這樣靜態(tài)頁面可以靈活的使用CDN、Nginx等形態(tài)部署。Edge Service屏蔽了內部微服務的結構，一般會搭配流量控制、安全認證等服務治理策略，使得內部服務能夠靈活的進行拆分合并，降低內部服務直接面對流量攻擊的風險。

點擊此處前往典型的Java Chassis云原生架構圖→

線程池是微服務的主要業(yè)務處理單元，合理的規(guī)劃線程池不僅可以最大限度提升系統(tǒng)性能，還能防止異常情況導致系統(tǒng)無法給正常用戶提供服務。線程池優(yōu)化和業(yè)務自身的性能有很大關系，不同的場景參數(shù)設置不同，需要具體分析。下面分兩種場景介紹。開始之前需要對業(yè)務的性能做一些基本的摸底，對常見的接口進行測試，查看時延。

業(yè)務性能很好的情況。

即非并發(fā)場景，接口的平均時延小于10ms。

業(yè)務性能很好的時候，為了讓業(yè)務系統(tǒng)具備更好的可預測性，防止JVM垃圾回收、網(wǎng)絡波動、突發(fā)流量等對系統(tǒng)的穩(wěn)定性造成沖擊，需要能夠快速丟棄請求，并配合重試等措施，以保障波動情況下系統(tǒng)性能可預測，同時不會出現(xiàn)偶然的業(yè)務失敗，影響體驗。

連接數(shù)和超時設置，業(yè)務線程池配置

業(yè)務性能不那么好的情況。

即非并發(fā)場景，接口的平均時延大于100ms。時延高通常是由于業(yè)務代碼存在IO、資源等等待，CPU利用率上不去導致的。如果是由于計算復雜導致的，調優(yōu)會變得復雜。

當業(yè)務性能不太好的時候，下面幾個參數(shù)值需要調大，否則業(yè)務會大量阻塞。業(yè)務性能不好，通過調大參數(shù)能夠保證系統(tǒng)的吞吐量，應對突發(fā)流量來臨時帶來的業(yè)務失敗。不過這個是以犧牲用戶體驗為代價的。

點擊此處前往配置線程池參數(shù)詳情→

推薦使用ServiceStage部署Java Chassis應用，使用ServiceStage能夠方便的實現(xiàn)滾動升級。當使用ServiceStage部署應用的時候，可以配置組件業(yè)務探針，使得ServiceStage能夠正確的檢測微服務的狀態(tài)。配置組件業(yè)務探針，需要啟用metrics功能，然后將組件業(yè)務探針路徑設置為“/health”。

除了設置探針，還需要設置滾動升級策略。核心的參數(shù)為“最大無效實例數(shù)”?！白畲鬅o效實例數(shù)”的默認值是0，當只有1個實例的情況下，滾動升級會存在中斷。建議設置實例數(shù)>=2，0<=最大無效實例數(shù)<實例數(shù) - 1即保證最小有2個可用的實例。

點擊此處前往規(guī)劃服務治理詳情→

要實現(xiàn)升級零中斷，通常需要解決如下問題：

1、停止服務的時候，可能引起業(yè)務中斷。在停止服務的過程中，可能服務正在處理請求，新的請求可能持續(xù)的發(fā)送到該服務。

2、在微服務架構下，一般都會通過注冊中心進行服務發(fā)現(xiàn)，客戶端會緩存實例地址。停止服務的時候，使用者可能無法及時感知實例下線，并繼續(xù)使用錯誤的實例進行訪問，導致失敗。

3、實現(xiàn)升級零中斷，需要進行滾動升級，在新版本功能就緒后，才能夠停止老版本。

實現(xiàn)升級零中斷需要很多的措施進行配合，比如滾動升級，實現(xiàn)零中斷，建議保證最小有2個可用的實例。在本章節(jié)里面，主要描述從微服務的角度進行設置，更好的配合升級零中斷。

點擊此處前往升級零中斷詳情→

持續(xù)升級版本，可以更好的使用微服務引擎CSE的新功能和新特性，及時修復已知的質量和安全問題，降低維護成本。持續(xù)升級版本也會帶來一些兼容性問題。一個比較好的策略是將持續(xù)升級納入版本計劃，安排足夠的時間進行，而不是以問題驅動。持續(xù)升級還需要構建自動化測試能力，以減少版本升級的驗證時間和控制版本升級的風險，及早發(fā)現(xiàn)問題。持續(xù)的構建自動化能力和升級版本，是被證明有效的構建高質量軟件的最佳實踐。

查看錯誤日志是定位問題的重要手段，需要合理規(guī)劃日志輸出，并且盡可能降低對系統(tǒng)性能的影響。規(guī)劃日志文件有如下建議：

1、使用log4j2或者logback輸出日志。 將日志輸出到文件，不要依賴于容器的stdout。

2、打開metrics日志，將metrics日志輸出到獨立的文件，比如“metrics.log”， 而將業(yè)務日志輸出到另外的文件，比如“servicecomb.log”。

3、打開access log， 將access log輸出到獨立的日志文件。

4、格式化打印業(yè)務日志，日志里面包含trace id，可以獨立開發(fā)一個Handler，配置在Provider Handler的最前面，Handler在接收到請求后打印一條日志，處理完成了打印一條日志，對于問題界定，使用AOM快速檢索相關日志等非常有幫助。

點擊此處前往配置日志文件詳情→