原文：http://blog.csdn.net/yeyincai/article/details/51470475
—.背景
談論服務化框架的時候，我們首先先了解這些概念：SOA、ESB、OSGi、servicemix、微服務、Spring Boot
SOA:面向服務架構，傳統簡單的網站系統采用MVC架構,隨着系統需求不斷的變化和業務不斷的擴展，MVC顯得很無力，MVC不斷的變大，維護開發越來越困難，SOA解決的是MVC里面大而核心的功能，抽離出來做成服務提供給不斷變化的業務使用。SOA提出多年，它僅僅是一個概念—一切皆服務，並不是一種技術的實現。
ESB:企業服務總線，是SOA 其中一種實現，打個比方，電商SOA包含會員、商品、支付、短信、物流等服務，比如用戶購買商品需要整合下面服務，登錄—>下單—>支付—>物流，ESB正是解決這種服務消息之間的路由規則,因此稱之為服務總線。
OSGi:面向java動態系統，它的基礎是動態化，目的是模塊化，目標是系統解耦。電商系統中：我們可以抽離支付為一個模塊，短信為一個模塊，用戶一個模塊、產品一個模塊,這樣拆分大系統,降低耦合,強調了一切皆模塊。
serviceMix:是apache下面一個支持OSGI的ESB容器，與普通的tomcat相比，tomcat運行的一個war包，serviceMix運行的是一個bundle（實質是jar包）；tomcat不能動態增刪模塊，serviceMix是可以；tomcat的war包之間不能調用，serviceMix可以引用同一個容器的bundle服務。
微服務:功能單一的服務，是相對與SOA的一種說法，SOA是胖服務，集成了整個系統所有的服務，而微服務強調微小，一個服務最好只做一件事。比如簽到微服務，短信微服務，它與OSGi目的都是一樣。
Spring Boot:微服務的一種實現及其運行方式，采用了優秀spring，但是剔除了繁瑣的XML配置，內嵌tomcat或者jetty等容器，極其簡單開發部署。
二.服務化引入
網站系統隨着不斷的發展，越來越復雜，架構的變遷也會從MVC—>SOA—>微服務,從簡單到復雜，從集中到分布，上面介紹的技術都是為了解決這些問題。服務化框架的引入是SOA—>微服務過程必須要解決的問題。面對服務的增多，服務分布的部署，服務與服務之間相互的調用，不得不使用服務化框架去解決。著名的dubbo就是這樣產生的。
三.服務化框架的簡介
服務化框架分為兩部分：rpc、注冊中心
1.rpc:遠程調用，遠程調用的傳輸協議有很多種，可以走http、webservice、tcp等。facebook的thrift、google的grpc、alibaba的dubbo世界上主流的rpc框架。其重點在於安全、快速、最好能跨語言。
2.注冊中心:用於存放，服務的ip地址和狀態信息等。比較好的存放服務信息的方案有:zookeeper、consul、redis。其重點在於避免單點問題，並且好維護。
四.服務化框架原理
根據上面圖，服務化原理可以分為3步：
1.服務端啟動並且向注冊中心發送服務信息，注冊中心收到后會定時監控服務
2.客戶端需要開始調用服務的時候，首先去注冊中心獲取服務信息
3.客戶端創建rpc連接，服務端返回處理信息
第3步又可以細分，下面說說rpc的原理：
目標：客戶端C類怎么調用遠程機器上S服務的a.say()方法
1）.服務發現，向注冊中心獲取服務(這里需要做的有很多：拿到多個服務時需要做負載均衡，同機房過濾、版本過濾、服務路由過濾等)
2）.客戶端發起調用，將需要調用的服務和方法和參數進行組裝
3）.序列化編碼組裝的消息，這里可以使用json，也可以使用xml，也可以使用protobuf，也可以使用hessian，幾種方案的序列化速度還有序列化后占用字節大小都是選擇的重要指標。
4）.傳輸協議，可以使用傳統的io阻塞傳輸，也可以使用高效的nio傳輸(netty)。
5）.服務端收到后進行反序列化，然后進行相應的處理。
6）.服務端序列化response信息並且返回。
7）.客戶端收到response信息並且反序列化。
五.服務化框架實現
以上介紹了服務化框架基本信息和原理。下面介紹服務化框架的實現。
選取一種注冊方案，鑒於zookeeper坑太多，偏向於選擇consul，consul不像zookeeper這么抽象，封裝了服務化的http api，非常方便調用，並且增加了對服務健康檢查。選取一種rpc方案，對比thrift和grpc，結合兩者的特性，grpc支持android ios app調用，功能更加強大，並且基於http2傳輸，多路復用，並發情況不需要創建多個線程進行管理，並且是使用的protobuf3進行序列化，高效快捷。
以上的方案選取好后，就可以進行代碼實現了
