上一篇博文中我們選定Openstack做爲我們的基礎設施IAAS平臺，本文將明確我們用什麼技術做爲微服務平臺的技術選型。
經過對微服務的特性總結和添加一些個性需求後對微服務平臺的基本要求
- PRC遠程調用，必須是TCP協議的，HTTP、HTTP/2不考慮，當然可以同時支持
- 服務發現
- 負載均衡
- 平滑升級，服務升級不影響線上業務
- 動態伸縮，阿里叫彈性計算
- 多語言支持，這個在後面專門解釋一下爲什麼要支持多語言
容錯等其它特性暫不考慮
選型
最早接觸的是阿里的EDAS（HSF）的微服務實現，後來知道他們有開源的Dubbo，再後來發現同類的RPC框架有Thrift、Zeroc Ice、Google的gRpc等，隨着深入瞭解發現大Spring也推出一個微服務開發框架叫Spring Cloud，這麼多業界大佬都相繼推出自家產品，看來微服務的前景大好！
這麼多框架帶來的問題了也是顯而易見的，用誰，怎麼用呢？
從大的格局上考慮，這麼多特性都支持的並沒有，比如Dubbo的服務發現要用Zookeeper等註冊中心來實現，Spring Cloud也是需要安裝很多組件來實現並且並不支持彈性和多語言，我本人是一個一切從簡的人，不喜歡把事情搞的太複雜也不好維護，直到看到這篇文章 http://www.infoq.com/cn/articles/netflix-oss-spring-cloud-kubernetes ，對Kubernets產生的濃厚的興趣，之前早聽過Kubernets一直以爲只是個Docker的編排工具沒曾想它還有這麼多功能，什麼服務發現、負載、彈性等一應俱全， 好，就是你了！
但RPC如何實現？
根據我們的要求支持TCP、多語言上面幾個就只剩下Thrift和Ice了，考慮到Thrift比較成熟有Apache做背景就沒有繼續研究Ice，另外看了下性能測試它倆相差不多
因此RPC框架就確定爲Apache Thrift !
那麼如何將Thrift跟Kubernets結合使用呢，我們將在下一篇博文中展開討論！