認識微服務

什麼是微服務？

微服務是一種架構風格。

它能夠經過強壯的模塊邊界和獨立部署，來幫助你快速的擴展開發團隊。

其實微服務自己不是什麼新技術，只是隨着業務的不斷髮展，對業務不斷分層，不斷拆分。

它被業界公認爲雲計算時代互聯網應用的主要構建方式，是每一位技術人員必須面對的主題。

爲何要使用微服務？

（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。

關注微信公衆號，留言便可，看到留言後會及時回覆。

IT小圈兒