怎樣認識微服務

本篇文章為大家展示了怎樣認識微服務，內容簡明扼要并且容易理解，絕對能使你眼前一亮，通過這篇文章的詳細介紹希望你能有所收獲。

什么是微服務？

微服務是一種架構風格。

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

其實微服務本身不是什么新技術，只是隨著業務的不斷發展，對業務不斷分層，不斷拆分。

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

為什么要使用微服務？

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

上述內容就是怎樣認識微服務，你們學到知識或技能了嗎？如果還想學到更多技能或者豐富自己的知識儲備，歡迎關注億速云行業資訊頻道。