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

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

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

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

該架構(gòu)采用靜態(tài)頁(yè)面和服務(wù)分離，這樣靜態(tài)頁(yè)面可以靈活的使用CDN、Nginx等形態(tài)部署。Edge Service屏蔽了內(nèi)部微服務(wù)的結(jié)構(gòu)，一般會(huì)搭配流量控制、安全認(rèn)證等服務(wù)治理策略，使得內(nèi)部服務(wù)能夠靈活的進(jìn)行拆分合并，降低內(nèi)部服務(wù)直接面對(duì)流量攻擊的風(fēng)險(xiǎn)。

點(diǎn)擊此處前往典型的Java Chassis云原生架構(gòu)圖→

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

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

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

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

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

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

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

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

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

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

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

點(diǎn)擊此處前往規(guī)劃服務(wù)治理詳情→

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

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

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

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

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

點(diǎn)擊此處前往升級(jí)零中斷詳情→

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

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

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

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

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

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

點(diǎn)擊此處前往配置日志文件詳情→