什麼是微服務？
微服務是一種架構風格。
它可以通過強壯的模組邊界和獨立部署，來幫助你快速的擴充套件開發團隊。
其實微服務本身不是什麼新技術，只是隨著業務的不斷髮展，對業務不斷分層，不斷拆分。
它被業界公認為雲端計算時代網際網路應用的主要構建方式，是每一位技術人員必須面對的主題。
為什麼要使用微服務？
（1）比如，公司的不同業務都會有不同管理後臺，每個後臺都有登入、註冊、許可權管理、日誌管理等模組。
這些模組在不同系統中基本上都是類似的，無需每次都拷貝程式碼。
So，開發一個微服務，管理基礎模組。
（2）比如，隨著業務的併發性越來越高，訪問DB數量過大，需要考慮引入快取層。
由於沒有統一快取服務，各個業務線都自己開發自己的快取層。
大家都做著重複工作，稍有不慎可能快取KEY產生衝突，造成資料混亂。
So，開發一個微服務，管理快取層。
（3）比如，各個業務線運算元據庫可直接進行拼接SQL查詢。
那麼經驗少一些的開發工程師，寫了一個低效率的SQL。
導致全表掃描直接卡死，直接影響到其他業務線系統的可用性。
DBA不好定位SQL是那個業務組，每次SQL調優都需要問候全部業務組。
So，開發一個微服務，實現資料調取層。
（4）...
應用場景還有很多...
大家可以根據各自業務進行服務拆分。
開發微服務應該考慮那些？
（1）衡量是否需要進行使用微服務？
微服務並不適合每個人，由於技術人員少或者專案並不多的情況下，就不需開發微服務。
（2）考慮服務到達怎麼的獨立程度？
微服務到底需要多微小，這個是根據自己的業務情況而定，沒有統一標準。
微服務並不是越微越好！！！
設計原則：是給自己提供便利，而不是自己給自己挖坑。
（3）是否對微服務進行實時監控？
隨著業務的越來越多，併發量，訪問量，儲存量 等等越來越大的時候。
需要考慮對微服務進行實時監控，考慮是否需要擴容，效能調優等等。
（4）微服務如何進行測試？
微服務使用的業務部門比較多，當新的業務部門使用時，如何便於測試？
在測試的過程中，遇到問題如何在不影響其他業務的同時進行修復？
實際事情實際考慮，最好能提供測試用例。
（5）微服務如何進行治理？
隨著專案的微服務越來越多，類似於“盤絲洞”的服務應該如何治理？
具體問題，具體分析吧，我這也沒具體思路，歡迎大家討論。
微服務的呼叫方式？
HTTP介面 或 RPC。
這兩種方式可以都試用下，具體那種更合適自己就選那種。
至於這兩種方式有什麼區別，我擔心我解釋完了大家更疑惑。
我個人推薦用 RPC（遠端過程呼叫協議）。
RPC 就像呼叫本地方法一樣，對呼叫者來說使用更方便。
RPC 開源框架很多，可以根據自己的開發語言進行選擇適合自己的。
PHP 常見的RPC框架： phprpc、yar、thrift、gRPC、swoole、hprose。
備註
本文僅僅是拋磚引玉，具體在實現的過程中，還有遇到很多問題。
歡迎大家進行討論~
Thanks ~
作者：PHP後端開發者
免費提供技術諮詢服務（自己懂的知識）。
QQ群：564557094。
關注微信公眾號，留言即可，看到留言後會及時回覆。
