什么是微服務(wù)？
微服務(wù)是一種架構(gòu)風(fēng)格。
它可以通過強(qiáng)壯的模塊邊界和獨(dú)立部署，來幫助你快速的擴(kuò)展開發(fā)團(tuán)隊(duì)。
其實(shí)微服務(wù)本身不是什么新技術(shù)，只是隨著業(yè)務(wù)的不斷發(fā)展，對業(yè)務(wù)不斷分層，不斷拆分。
它被業(yè)界公認(rèn)為云計(jì)算時(shí)代互聯(lián)網(wǎng)應(yīng)用的主要構(gòu)建方式，是每一位技術(shù)人員必須面對的主題。
為什么要使用微服務(wù)？
（1）比如，公司的不同業(yè)務(wù)都會(huì)有不同管理后臺(tái)，每個(gè)后臺(tái)都有登錄、注冊、權(quán)限管理、日志管理等模塊。
這些模塊在不同系統(tǒng)中基本上都是類似的，無需每次都拷貝代碼。
So，開發(fā)一個(gè)微服務(wù)，管理基礎(chǔ)模塊。
（2）比如，隨著業(yè)務(wù)的并發(fā)性越來越高，訪問DB數(shù)量過大，需要考慮引入緩存層。
由于沒有統(tǒng)一緩存服務(wù)，各個(gè)業(yè)務(wù)線都自己開發(fā)自己的緩存層。
大家都做著重復(fù)工作，稍有不慎可能緩存KEY產(chǎn)生沖突，造成數(shù)據(jù)混亂。
So，開發(fā)一個(gè)微服務(wù)，管理緩存層。
（3）比如，各個(gè)業(yè)務(wù)線操作數(shù)據(jù)庫可直接進(jìn)行拼接SQL查詢。
那么經(jīng)驗(yàn)少一些的開發(fā)工程師，寫了一個(gè)低效率的SQL。
導(dǎo)致全表掃描直接卡死，直接影響到其他業(yè)務(wù)線系統(tǒng)的可用性。
DBA不好定位SQL是那個(gè)業(yè)務(wù)組，每次SQL調(diào)優(yōu)都需要問候全部業(yè)務(wù)組。
So，開發(fā)一個(gè)微服務(wù)，實(shí)現(xiàn)數(shù)據(jù)調(diào)取層。
（4）...
應(yīng)用場景還有很多...
大家可以根據(jù)各自業(yè)務(wù)進(jìn)行服務(wù)拆分。
開發(fā)微服務(wù)應(yīng)該考慮那些？
（1）衡量是否需要進(jìn)行使用微服務(wù)？
微服務(wù)并不適合每個(gè)人，由于技術(shù)人員少或者項(xiàng)目并不多的情況下，就不需開發(fā)微服務(wù)。
（2）考慮服務(wù)到達(dá)怎么的獨(dú)立程度？
微服務(wù)到底需要多微小，這個(gè)是根據(jù)自己的業(yè)務(wù)情況而定，沒有統(tǒng)一標(biāo)準(zhǔn)。
微服務(wù)并不是越微越好！！！
設(shè)計(jì)原則：是給自己提供便利，而不是自己給自己挖坑。
（3）是否對微服務(wù)進(jìn)行實(shí)時(shí)監(jiān)控？
隨著業(yè)務(wù)的越來越多，并發(fā)量，訪問量，存儲(chǔ)量 等等越來越大的時(shí)候。
需要考慮對微服務(wù)進(jìn)行實(shí)時(shí)監(jiān)控，考慮是否需要擴(kuò)容，性能調(diào)優(yōu)等等。
（4）微服務(wù)如何進(jìn)行測試？
微服務(wù)使用的業(yè)務(wù)部門比較多，當(dāng)新的業(yè)務(wù)部門使用時(shí)，如何便于測試？
在測試的過程中，遇到問題如何在不影響其他業(yè)務(wù)的同時(shí)進(jìn)行修復(fù)？
實(shí)際事情實(shí)際考慮，最好能提供測試用例。
（5）微服務(wù)如何進(jìn)行治理？
隨著項(xiàng)目的微服務(wù)越來越多，類似于“盤絲洞”的服務(wù)應(yīng)該如何治理？
具體問題，具體分析吧，我這也沒具體思路，歡迎大家討論。
微服務(wù)的調(diào)用方式？
HTTP接口 或 RPC。
這兩種方式可以都試用下，具體那種更合適自己就選那種。
至于這兩種方式有什么區(qū)別，我擔(dān)心我解釋完了大家更疑惑。
我個(gè)人推薦用 RPC（遠(yuǎn)程過程調(diào)用協(xié)議）。
RPC 就像調(diào)用本地方法一樣，對調(diào)用者來說使用更方便。
RPC 開源框架很多，可以根據(jù)自己的開發(fā)語言進(jìn)行選擇適合自己的。
PHP 常見的RPC框架： phprpc、yar、thrift、gRPC、swoole、hprose。
備注
本文僅僅是拋磚引玉，具體在實(shí)現(xiàn)的過程中，還有遇到很多問題。
歡迎大家進(jìn)行討論 (留言、私信均可)~
Thanks ~
