什么是微服務约急？
微服務是一種架構風格。
它可以通過強壯的模塊邊界和獨立部署叙凡，來幫助你快速的擴展開發(fā)團隊。
其實微服務本身不是什么新技術密末，只是隨著業(yè)務的不斷發(fā)展握爷，對業(yè)務不斷分層，不斷拆分严里。
它被業(yè)界公認為云計算時代互聯(lián)網(wǎng)應用的主要構建方式新啼，是每一位技術人員必須面對的主題。
為什么要使用微服務刹碾？
（1）比如燥撞，公司的不同業(yè)務都會有不同管理后臺，每個后臺都有登錄、注冊物舒、權限管理色洞、日志管理等模塊。
這些模塊在不同系統(tǒng)中基本上都是類似的冠胯，無需每次都拷貝代碼火诸。
So，開發(fā)一個微服務涵叮，管理基礎模塊惭蹂。
（2）比如伞插，隨著業(yè)務的并發(fā)性越來越高割粮，訪問DB數(shù)量過大，需要考慮引入緩存層媚污。
由于沒有統(tǒng)一緩存服務舀瓢，各個業(yè)務線都自己開發(fā)自己的緩存層。
大家都做著重復工作耗美，稍有不慎可能緩存KEY產生沖突京髓，造成數(shù)據(jù)混亂。
So商架，開發(fā)一個微服務堰怨，管理緩存層。
（3）比如蛇摸，各個業(yè)務線操作數(shù)據(jù)庫可直接進行拼接SQL查詢备图。
那么經(jīng)驗少一些的開發(fā)工程師，寫了一個低效率的SQL赶袄。
導致全表掃描直接卡死揽涮，直接影響到其他業(yè)務線系統(tǒng)的可用性。
DBA不好定位SQL是那個業(yè)務組饿肺，每次SQL調優(yōu)都需要問候全部業(yè)務組蒋困。
So，開發(fā)一個微服務敬辣，實現(xiàn)數(shù)據(jù)調取層雪标。
（4）...
應用場景還有很多...
大家可以根據(jù)各自業(yè)務進行服務拆分。
開發(fā)微服務應該考慮那些溉跃？
（1）衡量是否需要進行使用微服務村刨？
微服務并不適合每個人，由于技術人員少或者項目并不多的情況下喊积，就不需開發(fā)微服務烹困。
（2）考慮服務到達怎么的獨立程度？
微服務到底需要多微小乾吻，這個是根據(jù)自己的業(yè)務情況而定髓梅，沒有統(tǒng)一標準拟蜻。
微服務并不是越微越好！？荻觥酝锅！
設計原則：是給自己提供便利，而不是自己給自己挖坑奢方。
（3）是否對微服務進行實時監(jiān)控搔扁？
隨著業(yè)務的越來越多，并發(fā)量蟋字，訪問量稿蹲，存儲量 等等越來越大的時候。
需要考慮對微服務進行實時監(jiān)控鹊奖，考慮是否需要擴容苛聘，性能調優(yōu)等等。
（4）微服務如何進行測試忠聚？
微服務使用的業(yè)務部門比較多设哗，當新的業(yè)務部門使用時，如何便于測試两蟀？
在測試的過程中网梢，遇到問題如何在不影響其他業(yè)務的同時進行修復？
實際事情實際考慮赂毯，最好能提供測試用例战虏。
（5）微服務如何進行治理？
隨著項目的微服務越來越多欢瞪，類似于“盤絲洞”的服務應該如何治理活烙？
具體問題，具體分析吧遣鼓，我這也沒具體思路啸盏，歡迎大家討論。
微服務的調用方式骑祟？
HTTP接口 或 RPC回懦。
這兩種方式可以都試用下，具體那種更合適自己就選那種次企。
至于這兩種方式有什么區(qū)別怯晕，我擔心我解釋完了大家更疑惑。
我個人推薦用 RPC（遠程過程調用協(xié)議）缸棵。
RPC 就像調用本地方法一樣舟茶，對調用者來說使用更方便。
RPC 開源框架很多，可以根據(jù)自己的開發(fā)語言進行選擇適合自己的吧凉。
PHP 常見的RPC框架： phprpc隧出、yar、thrift阀捅、gRPC胀瞪、swoole、hprose饲鄙。
備注
本文僅僅是拋磚引玉凄诞，具體在實現(xiàn)的過程中，還有遇到很多問題忍级。
歡迎大家進行討論 (留言帆谍、私信均可)~
Thanks ~
