重點來了，本文全面闡述一下我們的RPC是怎麼實現並如何使用的，跟Kubernetes和Openstack怎麼結合。
在選型一文中說到我們選定的RPC框架是Apache Thrift，它的用法是在Main方法中重啟服務，在Client端連接服務去調用。而我的想法是要跟Dubblo、HSF的用法一樣，因為很多人都熟悉這兩個框架的用法，特別是我們好幾個項目都是基於EDAS開發的，而且世面上用Dubbo的公司也很多。順便再說一下我們對於RPC的幾點要求：1，兼容Dubbo和HSF的使用方法，支持版本和服務分組，支持項目隔離2，客戶端重試機制，可以配置次數和間隔時間3，客戶端線程池4，服務端可以平滑無縫升級而不影響客戶端的使用
兼容Dubbo就必然要使用Spring框架，那我們就直接上Spring Boot好了，號稱Spring Boot為微服務開發而生，一步到位，將Thrift跟Spring Boot整合。
版本和服務分組可以通過Kubernetes的Service的Label來實現，我們客戶端在查找服務的時候通過這兩個標籤再加上接口類的Label來定位Service的Cluster IP，這裡不直接使用Service名稱來調用服務的原因是通過Label查詢Servcie更加靈活一些，Service的名稱不受限制，隨時可以啟動一個帶有相同Label的新Service來替換舊的Service.
項目隔離可以用Kubernetes的namespace來實現，一個namespace是一個項目，當然項目之間也可以互相調用，默認情況下是整個Kubernetes集群的服務都是可以被調用到的如果在沒有指定namespace的情況下。
客戶端重試機制用代理Thrift連接的方式來實現，在連接或接口方法調用異常時發起重新連接。
客戶端連接池是由於在WEB項目中每次用戶發起請求是在一個獨立的線程中，而Thrift的Client Socket連接不是線程安全的，因此要為每個用戶準備一個Socket連接，有點像資料庫的連接池，這個可以用apache的commons pool2來實現，這個有很多網友的文章可以參考，本文就不在贅述了。