一個項目，從開始到版本更新，一直到最後的版本維護。功能在不斷增多，對應的代碼量也在不斷增加，也就意味着項目變得更不可維護，這時候，我們需要用拆分的方式将一個項目打散，以便開發團隊更好的對項目進行維護。
這個階段，一般也是項目的初級階段，由于人手不夠，一個服務端的接口項目隻有一個開發進行維護，根據開發的習慣，會把項目分成若幹個子產品進行開發，在一個項目下進行部署。
這樣做的缺點在于項目會随着版本更新而變得不可維護。
随着每個子產品功能的不斷完善，代碼變得更加臃腫。這時候需要對項目進行拆分，比如上面的圖，分成使用者體系項目、支付體系項目。
開始大家會采用CURL的方式對外部資源進行通路。
比如某短信平台SDK,比如各大第三方提供的SDK,糾結到源碼發現都是直接采用CURL函數的方式進行通路。
優點在于沒有環境要求，能直接用。
缺點在于并發通路的資源占用問題。
遠端過程調用協定
RPC（Remote Procedure Call Protocol）——遠端過程調用協定，它是一種通過網絡從遠端計算機程式上請求服務，而不需要了解底層網絡技術的協定。RPC協定假定某些傳輸協定的存在，如TCP或UDP，為通信程式之間攜帶資訊資料。在OSI網絡通信模型中，RPC跨越了傳輸層和應用層。RPC使得開發包括網絡分布式多程式在内的應用程式更加容易。 RPC采用客戶機/伺服器模式。請求程式就是一個客戶機，而服務提供程式就是一個伺服器。首先，客戶機調用程序發送一個有程序參數的調用資訊到服務程序，然後等待應答資訊。在伺服器端，程序保持睡眠狀态直到調用資訊到達為止。當一個調用資訊到達，伺服器獲得程序參數，計算結果，發送答複資訊，然後等待下一個調用資訊，最後，用戶端調用程序接收答複資訊，獲得程序結果，然後調用執行繼續進行。
鳥哥出品的RPC架構，輕量級架構。
調用代碼
注意的是鳥哥出的東西文檔比較少，需要多調試。
thrift是一個軟體架構，用來進行可擴充且跨語言的服務的開發。它結合了功能強大的軟體堆棧和代碼生成引擎，以建構在 C++, Java, Python, PHP, Ruby, Erlang, Perl, Haskell, C#, Cocoa, JavaScript, Node.js, Smalltalk, and OCaml 這些程式設計語言間無縫結合的、高效的服務。
遠端調用的意義在于，不同的子項目可以用更适合自己的語言來解決，更有效率的實作需求。
同時，對團隊的開發來講，更能提高整體的技術水準。
由于用的XML就不多描述了，畢竟還是json用的多。
下面是傳回值的标準
實際上你會發現我們在給用戶端提供接口的傳回值，就是按照這個标準來做的。
相應的，服務端對服務端的資料接收和傳回，也要同樣按照這個标準來做。
一個子產品對應一個項目，項目之間通過基于REST的接口标準進行面向資源的資料通路。
項目拆分的前提是一個項目不足以滿足現有的業務發展要求，也就意味着拆分之後的開發人員數量的擴增。
遊擊隊向正規軍編制的跨越！
更多的項目也就意味着更多的接口調用文檔，适當的處理文檔才能更好的提高團隊協作效率。
服務的遠端調用在于怎麼合理的把一個正在變得不可維護的項目從焦油坑中解救出來，并提高項目整體能承載的業務量，不過，世界上沒有銀彈。
<a href="http://www.laruence.com/2012/09/15/2779.html">http://www.laruence.com/2012/09/15/2779.html</a>
<a href="https://segmentfault.com/q/1010000000318121">https://segmentfault.com/q/1010000000318121</a>
<a href="http://wiki.geekdream.com/Specification/json-rpc_2.0.html">http://wiki.geekdream.com/Specification/json-rpc_2.0.html</a>
人月神話