眾所周知，JSF是基於Java的RPC框架併在其基礎上提供了一些服務治理功能，目前被廣泛應用於集團內部。但隨著微服務及容器化在京東日益深入普及，服務種類及服務實體數急劇增加，部署場景也從單純內部使用開始向外部延伸出現混合部署的新情況，特別是元件化及對外賦能戰略的提出，都對JSF提出了更新、更高的要求。總結一下，這些要求包括如下：
-
呼叫端依賴的服務個數及每個服務的實體數越來越多，造成呼叫端的啟動越來越慢；
-
當前的軟負載均衡策略遇到挑戰，急需最佳化、調整；
-
跨應用、跨系統的呼叫越來越多，呼叫關係和依賴關係日益複雜，可觀察性越來越差；
-
混合部署需要支援多註冊中心，不同的服務訪問不同的註冊中心；
-
各服務的資訊比如入參/出參等散落在各個地方，服務呼叫者無法快速、準確、全面獲取這些知識，溝通成本非常高；
-
跨語言支援日益迫切，基於庫方式將開發者綁死在單一技術棧上，與微服務理念相悖；
-
缺乏靈活、智慧、貼近業務場景及業務架構的流量控制機制及相應的運維支援手段；
-
缺乏靈活、適度的安全機制；特性增加與BUG修複升級非常困難。
客觀上講，JSF還是很成功的，當前它支撐了幾萬服務介面，幾十萬的JVM實體，在今年雙十一大促季峰值呼叫量近四千億次，這些數字足以表明JSF還是非常優秀的。但是，隨著業界“容器化”、“雲原生應用”等大潮的到來以及集團元件化對外賦能戰略的提出，JSF逐漸遇到了“危機”，亟待重整旗鼓，順應技術潮流的發展，再創輝煌！
經過認真分析，我們認為要徹底解決JSF面臨的上述問題，需要從多角度、全方位進行深入細緻的最佳化與再造工作。這些工作不僅涉及到了RPC框架本身，還涉及到了基於該框架之上的微服務治理等工作，以及最後為滿足使用者各種場景下的需求而提供的一系列操作及API，它們之間存在明顯的層次劃分，層與層之間相互支撐，共同協作，就像下圖所示那樣。我們把所有這些正在做以及即將做的工作統一命名為“微服務平臺”，該平臺的出現宣告了京東微服務工作已經從過去“偏於底層技術建設”向上延伸，發展到了透過提供各種上層功能模組充分與應用場景及應用架構相連線的“平臺生態建設”上來。下麵我們按照層次劃分，從下往上介紹平臺組成。
微服務軟體架構大行其道的重要技術因素就是容器及容器編排系統的出現，JDOS作為京東容器叢集平臺，理所應當成為JSF最重要的基礎設施；目前JSF所有的功能模組全部執行在容器上，而且還跟JDOS2.0進行了若干功能整合；未來JSF還將與JDOS進行更多、更深入的合作，為JSF打造一個堅實、穩定的技術底座。
該層是JSF的基礎層，包括了JSF SDK、正在研發的京東服務網格（ContainerMesh）以及服務發現機制（JSF Registry）；另外，我們接下來將著力打造全新的通訊安全體系，全方位提升JSF的安全性。
該層基於服務框架層，提供了更多的擴充套件功能，是下層功能的自然延伸，包括微服務呼叫圖譜（解決“微服務大爆炸”後可觀察性差的問題）、微服務流控（提供了各種流量控制切換的機制）、微服務配置中心（提供了支援各種格式的服務配置資訊）以及微服務監控（我們將和UMP合作，提供更加強大的效能監控服務）。
該層基於下層提供的基礎功能，打造了“服務集市”這一全新的應用樣式，在集市裡可以進行服務檢索、服務依賴關係查詢、服務質量評價（重要性、健康度、架構合理性）、圍繞某個服務的評論互動，甚至包括服務使用資源上的評估等等。我們希望服務集市能夠將JSF和業務更加緊密的結合，提供貼近使用場景和應用架構的功能服務。
接下來，我們按照這個層次圖分別詳細介紹各層的功能。
由於缺乏集中管理機制，開發人員只能把提供的服務的知識放在cf或者jpcloud上，造成資訊過於分散，極大增加了相關人員的找尋與溝通成本，急需專門的管理中心來解決集中存放和查詢的問題，由此服務集市應運而生。
-
檢索
除了支援按基本屬性查詢外，還支援按擴充套件屬性查詢；除了支援模糊查詢外，還支援按類目查詢，比如按“交易類”、“商家類”、“金融類”、“物流類”等類目進行查詢。
-
知識庫
提供全方位、多維度的服務知識，除了提供服務基本的出/入引數詳情、負責人等組織架構資訊外，還提供了服務當前的執行指標資料，比如QPS/TP情況/可用率等；提供服務檔案（包括已經終止的服務），記錄某服務生命週期各階段的情況，包括版本變化及各版本對應的介面服務詳細資訊，以方便事後審計；提供服務快照功能，方便把服務在某個時刻的狀態記錄下來，比如大促時刻的狀態。
-
許可權認證
提供相關的流程控制，比如呼叫申請、服務終止申請、服務訪問授權等；
-
質量跟蹤
提供服務重要性評估、服務健康度評估、服務架構合理性評估，並提出相應建議；
-
呼叫關係
結合微服務呼叫圖譜，提供服務的呼叫鏈資訊，以便瞭解服務的相關依賴關係及鏈路屬性；
-
資源評估
提供資源使用情況，以配合相關人評價該服務是否有足夠能力滿足新的呼叫需求；還提供測試環境，以供臨時測試體驗，而不需要去挨個找對應服務的測試環境；
-
評價互動
提供服務輸出者和使用者的互動功能；整合相關係統上對服務的評價資訊，給服務使用者更加全面的知識。
隨著微服務數量的急劇增加，跨應用、跨系統的呼叫越來越多，呼叫關係和依賴關係日益複雜，出現了所謂的“微服務大爆炸”。微服務呼叫圖譜透過提供跨網路的呼叫堆疊分析，使我們既能從宏觀上俯瞰紛繁的業務關係及呼叫鏈整體特質，又能從微觀上觀察和審視呼叫鏈上各環節的細節，透過多種分析手段，給應用全方位畫像，形成一系列的圖譜，徹底解決“微服務大爆炸”後帶來的可觀察性差的問題。該系統提供瞭如下的分析：
-
來源分析：分析某服務的直接呼叫者的情況
-
入口分析：分析某服務的最初呼叫者（入口）的情況
-
路徑分析：分析一條完整呼叫鏈的情況
-
耗時分析：分析一條呼叫鏈中的各個環節的耗時情況
-
瓶頸分析：分析一條呼叫鏈中的瓶頸點的情況
-
依賴度分析：分析一條呼叫鏈中的強依賴、若依賴等的情況
目前該系統支援JSF/JMQ/JIMDB/各種資料庫連線池等中介軟體，接入應用超過1600個，涉及IP數超過37000個。下圖是由該系統生成的全域性呼叫關係圖：
在JSF的使用過程中，業務給我們提出了許多跟流控及運維相關的需求，我們將在微服務平臺中給予集中的解決，它們包括如下：
-
流量控制中要支援“版本”的概念（比如在一個分組中有兩個版本，現在需要對其中一個版本的實體進行操作）；
-
提供平滑的灰度升級和回退手段，支援A/B測試、金絲雀部署等；
-
支援動態配置（不需要反覆修改程式-打包-重新上線），這些動態配置的取值往往不可預測，需要根據實際情況隨時調整，比如流量的閾值、服務超時時間等；
-
服務永久下線的全流程支援（經常有業務為了下線一個即將廢棄的服務，而一遍遍的發郵件確認是否有人還在呼叫該服務）；
-
臨界條件下的強制降級、限流和熔斷等；
-
廢棄介面的治理，將長期沒有呼叫量的介面，定期給相關人發通告，讓他們下線。必要時，可以主動將它們下線，然後回收相應的資源。
配置資訊是軟體的重要一環，幾乎每個服務都有自己特殊的配置，比如各種控制開關、降級開關、K-V資訊等等。微服務配置中心支援普通字串、json、properties等的配置格式，並且提供了Restful的K-V的API，實現了跨語言、跨平臺。透過該系統，使用者可以實現服務功能的動態配置，從而避免了先下線->修改配置->再重新上線的麻煩。目前，該系統已經存放了460多GB的配置資訊。
JSF當前的監控功能還很弱，監控粒度也粗，沒有TP效能資料，不支援“秒級監控”。我們將跟UMP團隊展開合作，全面提升JSF在監控方面的能力和體驗。
JSF SDK是微服務平臺最早的核心模組，目前已經執行在幾乎所有的京東容器上，負責完成所有的服務通訊工作。但隨著京東業務不斷發展，JSF SDK也遇到了挑戰，突出表現為：擴充套件性和靈活性不夠。對此，我們重點將從以下幾方面進行解決。
-
增加更多的探針
在通訊過程的各個環節（編解碼、序列化等）加入探針邏輯，並透過開關控制，當出現諸如效能問題時，可以開啟開關，透過探針邏輯輸出的日誌來定位瓶頸點；沒有問題時，將開關關閉，避免影響效能。
-
增加更多的擴充套件點
在諸如序列化、路由決策等地方，提供擴充套件點，允許使用者提供定製的功能實現，來滿足他們的個性化需求。
-
開發新通訊協議
開發新一代的TCP通訊協議，加強協議頭部的能力，並加入握手階段，解決很多控制方面的短板，比如安全認證、路由等。
-
增加相關註解
提供跟服務介面相關的註解，自動收集服務介面資訊，為微服務集市收集資料，以降低手動錄入的工作量。
-
支援服務擴充套件屬性
當前JSF服務的屬性是固定的，不允許使用者擴充套件屬性，由此引發了一個深層次問題：業務只能按照JSF的規則來組織服務關係，而不能自定義服務關係，帶來的後果就是一旦業務場景或業務架構跟JSF組織的服務關係不匹配，就會出現本來彼此相關的一系列服務被割裂的現象，業務只能逐個處理，而不能整體處理，就像下圖所示的那樣：
左邊是個單體應用，一共由4個彼此依賴的服務構成，當該應用需要下線時，4個服務會同時下線（因為它們在同一行程空間中）；而在右邊，它們被微服務化，由不同開發小組來維護，當一個服務需要下線時，實際上需要其他服務一起下線，從而構成一個“有機的微服務集”，此時只能靠擴充套件屬性，將它們“邏輯”地系結在一起，進行整體下線，否則只能一個個下線，非常麻煩，效率低還易出錯。透過該功能特性，使得使用者能自由、靈活地按照實際的業務場景或架構來組合形成“有機的微服務集”，進行整體操作，從而提高效率。
JSF SDK以jar包的形式提供給Java開發者，這種基於“語言庫”的交付方式現在受到了越來越多的詬病。隨著集團業務領域的不斷擴充套件，不同領域內都有自己獨特的生態系統，都有最適合的開發語言，Java一枝獨秀的情況將在京東不復存在，Go、Python、C/C++、Node.js等語言會越來越多地出現在我們面前。另外，基於“語言庫”的方式還給特性升級和BUG修複帶來了困擾，無法做到業務無感知。
對此，我們正在開發京東自己的服務網格技術，力圖將業務邏輯與諸如通訊、服務治理等非業務邏輯進行徹底解耦，使得開發分散式應用跟開發單機應用一樣簡單。屆時，透過服務網格技術，不同語言之間可以順暢通訊，同時還相容JSF服務；當需要增加新的治理功能時，可以透明升級實現，業務沒有任何感知。
服務發現在微服務架構中扮演了極為重要的角色，JSF Registry是京東完全自研的支援多資料中心、跨廣域網、具有完備容災特性的服務發現系統。目前，該系統穩定地支援了近3萬個服務介面，近30萬個JVM實體的服務註冊/訂閱/配置推送等功能。
由於JSF執行在公司內網，所以安全性問題一直不是重點關註物件，但是隨著對外開放賦能不斷深化以及公司體量的不斷增大，不少服務提供方紛紛要求提高服務的安全性，從而保護自身服務的穩定執行，就想下圖所示那樣：
左邊是當前的情況，訪問不需要身份認證和授權，只要知道服務介面的相關資訊就能訪問，雖然有token機制，但是極易被突破。右邊是新的安全模型，在該模型中，每個服務都有一個全域性唯一ID（UUID），基於該ID，會進行證書管理、秘鑰管理以及身份認證、訪問授權等安全行為。為了兼顧靈活性和效率，還支援名稱空間和安全級別，同一名稱空間內的服務可以隨意通訊，不同名稱空間的訪問受管控；不同級別有不同的安全要求，比如達到某種級別的服務必須有服務提供方的授權才能訪問。
本次培訓內容包括：Docker容器的原理與基本操作；容器網路與儲存解析；Kubernetes的架構與設計理念詳解；Kubernetes的資源物件使用說明；Kubernetes 中的開放介面CRI、CNI、CSI解析；Kubernetes監控、網路、日誌管理；容器應用的開發流程詳解等，點選識別下方二維碼加微信好友瞭解具體培訓內容。
3月23日開始上課，最後8個名額，點選閱讀原文連結即可報名。
長按二維碼向我轉賬
受蘋果公司新規定影響，微信 iOS 版的贊賞功能被關閉，可透過二維碼轉賬支援公眾號。
知識星球
