微服務簡介
微服務是一個新興的軟件架構，就是把一個大型的單個應用程序和服務拆分為數十個的支持微服務。一個微服務的策略可以讓工作變得更為簡便，它可擴展單個組件而不是整個的應用程序。簡而言之，微服務架構是一種將單應用程序作為一套小型服務開發的方法，每種應用程序都在其自己的進程中運行，並與輕量級機制（通常是HTTP資源的API）進行通信。
微服務應用的一個最大的優點是，它們往往比傳統的應用程序更有效地利用計算資源。這是因為它們通過擴展組件來處理功能瓶頸問題。這樣一來，開發人員只需要為額外的組件部署計算資源，而不需要部署一個完整的應用程序的全新迭代。最終的結果是有更多的資源可以提供給其它任務。
微服務應用程序的另一個好處是，它們更快且更容易更新。當開發者對一個傳統的單體應用程序進行變更時，他們必須做詳細的QA測試，以確保變更不會影響其他特性或功能。但有了微服務，開發者可以更新應用程序的單個組件，而不會影響其他的部分。測試微服務應用程序仍然是必需的，但它更容易識別和隔離問題，從而加快開發速度並支持DevOps和持續應用程序開發。
rest、springmvc、http詳解
HTTP 協議:超文本傳輸協議，對應於應用層，用於如何封裝數據.
TCP/UDP 協議:傳輸控制協議，對應於傳輸層，主要解決數據在網絡中的傳輸。
IP 協議:對應於網絡層，同樣解決數據在網絡中的傳輸。
傳輸數據的時候只使用 TCP/IP 協議(傳輸層)，如果沒有應用層來識別數據內容，傳輸后的協議都是無用的。
應用層協議很多 FTP,HTTP,TELNET等，可以自己定義應用層協議。
web 使用 HTTP 作應用協議，以封裝 HTTP 文本信息，然后使用 TCP/IP 做傳輸層協議，將數據發送到網絡上。
http 為短連接：客戶端發送請求都需要服務器端回送響應.請求結束后，主動釋放鏈接，因此為短連接。通常的做法是，不需要任何數據，也要保持每隔一段時間向服務器發送"保持連接"的請求。這樣可以保證客戶端在服務器端是"上線"狀態。
HTTP連接使用的是"請求-響應"方式，不僅在請求時建立連接，而且客戶端向服務器端請求后，服務器才返回數據。
在HTTP和RPC的選擇上, 有些RPC框架配置復雜，如果走HTTP也能完成同樣的功能，那么為什么要選擇RPC，而不是更容易上手的HTTP來實現。
HTTP和RPC的異同如下所示:
傳輸協議
RPC，可以基於TCP協議，也可以基於HTTP協議
HTTP，基於HTTP協議
傳輸效率
RPC，使用自定義的TCP協議，可以讓請求報文體積更小，或者使用HTTP2協議，也可以很好的減少報文的體積，提高傳輸效率
HTTP，如果是基於HTTP1.1的協議，請求中會包含很多無用的內容，如果是基於HTTP2.0，那么簡單的封裝以下是可以作為一個RPC來使用的，這時標准RPC框架更多的是服務治理
性能消耗，主要在於序列化和反序列化的耗時
RPC，可以基於thrift實現高效的二進制傳輸
HTTP，大部分是通過json來實現的，字節大小和序列化耗時都比thrift要更消耗性能
負載均衡
RPC，基本都自帶了負載均衡策略
HTTP，需要配置Nginx，HAProxy來實現
服務治理（下游服務新增，重啟，下線時如何不影響上游調用者）
RPC，能做到自動通知，不影響上游
HTTP，需要事先通知，修改Nginx/HAProxy配置
總結：RPC主要用於公司內部的服務調用，性能消耗低，傳輸效率高，服務治理方便。HTTP主要用於對外的異構環境，瀏覽器接口調用，APP接口調用，第三方接口調用等。
HTTP服務對於企業開發的模式一直定性為HTTP接口開發，也就是常說的RESTful風格的服務接口。對於在接口不多、系統與系統交互較少的情況下，解決信息孤島初期常使用的一種通信手段；優點就是簡單、直接、開發方便。利用現成的http協議進行傳輸。進行接口的開發，還要寫一大份接口文檔，嚴格地標明輸入輸出是什么，說清楚每一個接口的請求方法，以及請求參數需要注意的事項等。比如下面這個例子：POST http://www.httpexample.com/restful/buyer/info/share接口可能返回一個JSON字符串或者是XML文檔。然后客戶端再去處理這個返回的信息，從而可以比較快速地進行開發。但是對於大型企業來說，內部子系統較多、接口非常多的情況下，RPC框架的好處就顯示出來了，首先就是長鏈接，不必每次通信都要像http一樣去3次握手什么的，減少了網絡開銷；其次就是RPC框架一般都有注冊中心，有豐富的監控管理；發布、下線接口、動態擴展等，對調用方來說是無感知、統一化的操作。總結RPC服務和HTTP服務還是存在很多的不同點的，一般來說，RPC服務主要是針對大型企業的，而HTTP服務主要是針對小企業的，因為RPC效率更高，而HTTP服務開發迭代會更快。