資訊專欄INFORMATION COLUMN
摘要：，開發(fā)一個微服務，實現(xiàn)數(shù)據(jù)調(diào)取層。微服務并不是越微越好設計原則是給自己提供便利，而不是自己給自己挖坑。需要考慮對微服務進行實時監(jiān)控，考慮是否需要擴容，性能調(diào)優(yōu)等等。微服務的調(diào)用方式接口或。
什么是微服務？
微服務是一種架構(gòu)風格。
它可以通過強壯的模塊邊界和獨立部署，來幫助你快速的擴展開發(fā)團隊。
其實微服務本身不是什么新技術，只是隨著業(yè)務的不斷發(fā)展，對業(yè)務不斷分層，不斷拆分。
它被業(yè)界公認為云計算時代互聯(lián)網(wǎng)應用的主要構(gòu)建方式，是每一位技術人員必須面對的主題。
為什么要使用微服務？
（1）比如，公司的不同業(yè)務都會有不同管理后臺，每個后臺都有登錄、注冊、權限管理、日志管理等模塊。
這些模塊在不同系統(tǒng)中基本上都是類似的，無需每次都拷貝代碼。
So，開發(fā)一個微服務，管理基礎模塊。
（2）比如，隨著業(yè)務的并發(fā)性越來越高，訪問DB數(shù)量過大，需要考慮引入緩存層。
由于沒有統(tǒng)一緩存服務，各個業(yè)務線都自己開發(fā)自己的緩存層。
大家都做著重復工作，稍有不慎可能緩存KEY產(chǎn)生沖突，造成數(shù)據(jù)混亂。
So，開發(fā)一個微服務，管理緩存層。
（3）比如，各個業(yè)務線操作數(shù)據(jù)庫可直接進行拼接SQL查詢。
那么經(jīng)驗少一些的開發(fā)工程師，寫了一個低效率的SQL。
導致全表掃描直接卡死，直接影響到其他業(yè)務線系統(tǒng)的可用性。
DBA不好定位SQL是那個業(yè)務組，每次SQL調(diào)優(yōu)都需要問候全部業(yè)務組。
So，開發(fā)一個微服務，實現(xiàn)數(shù)據(jù)調(diào)取層。
（4）...
應用場景還有很多...
大家可以根據(jù)各自業(yè)務進行服務拆分。
開發(fā)微服務應該考慮那些？
（1）衡量是否需要進行使用微服務？
微服務并不適合每個人，由于技術人員少或者項目并不多的情況下，就不需開發(fā)微服務。
（2）考慮服務到達怎么的獨立程度？
微服務到底需要多微小，這個是根據(jù)自己的業(yè)務情況而定，沒有統(tǒng)一標準。
微服務并不是越微越好?。?！
設計原則：是給自己提供便利，而不是自己給自己挖坑。
（3）是否對微服務進行實時監(jiān)控？
隨著業(yè)務的越來越多，并發(fā)量，訪問量，存儲量 等等越來越大的時候。
需要考慮對微服務進行實時監(jiān)控，考慮是否需要擴容，性能調(diào)優(yōu)等等。
（4）微服務如何進行測試？
微服務使用的業(yè)務部門比較多，當新的業(yè)務部門使用時，如何便于測試？
在測試的過程中，遇到問題如何在不影響其他業(yè)務的同時進行修復？
實際事情實際考慮，最好能提供測試用例。
（5）微服務如何進行治理？
隨著項目的微服務越來越多，類似于“盤絲洞”的服務應該如何治理？
具體問題，具體分析吧，我這也沒具體思路，歡迎大家討論。
微服務的調(diào)用方式？
HTTP接口 或 RPC。
這兩種方式可以都試用下，具體那種更合適自己就選那種。
至于這兩種方式有什么區(qū)別，我擔心我解釋完了大家更疑惑。
我個人推薦用 RPC（遠程過程調(diào)用協(xié)議）。
RPC 就像調(diào)用本地方法一樣，對調(diào)用者來說使用更方便。
RPC 開源框架很多，可以根據(jù)自己的開發(fā)語言進行選擇適合自己的。
PHP 常見的RPC框架： phprpc、yar、thrift、gRPC、swoole、hprose。
備注
本文僅僅是拋磚引玉，具體在實現(xiàn)的過程中，還有遇到很多問題。
歡迎大家進行討論 ~
推薦閱讀系統(tǒng)的講解 - SSO 單點登錄
系統(tǒng)的講解 - PHP WEB 安全防御
系統(tǒng)的講解 - PHP 緩存技術
系統(tǒng)的講解 - PHP 接口簽名驗證
系統(tǒng)的講解 - PHP 浮點數(shù)高精度運算
文章版權歸作者所有，未經(jīng)允許請勿轉(zhuǎn)載,若此文章存在違規(guī)行為，您可以聯(lián)系管理員刪除。
轉(zhuǎn)載請注明本文地址：http://www.ezyhdfw.cn/yun/22280.html
摘要：缺點系統(tǒng)依賴復雜，給開發(fā)測試部署帶來不便，分布式數(shù)據(jù)一致性和分布式事務支持困難，一般通過最終一致性簡化解決。微服務架構(gòu)分成三種實現(xiàn)模式。事件驅(qū)動架構(gòu)事件是狀態(tài)發(fā)生變化時，軟件發(fā)出的通知。事件驅(qū)動架構(gòu)的四個部分事件隊列接收事件的入口。 架構(gòu)的規(guī)劃誰架構(gòu)就是對系統(tǒng)中的實體以及實體之間的關系所進行的抽象描述，是決策。...
摘要：前幾天寫一篇，一種新思路實現(xiàn)分布式事務的文章。寫個分布式事務就有人開始噴了事務提交了，怎么回滾都知道怎么回滾。 前幾天寫一篇 ， 一種新思路實現(xiàn)分布式事務的文章。https://segmentfault.com/a/11... 部分死腦筋就開始，各種不解?？捶答?確實有點搞笑。 不要一聽到 session 就覺得是 $_SEESION不要別人換個名字 token 或者 jwt 就不認識...
摘要：公司始于名為的平臺即服務供應商?？缍鄠€機器之間協(xié)調(diào)這些容器需要額外的工具，這稱之為容器編排。的核心優(yōu)勢是為應用程序開發(fā)人員提供了用于編排無狀態(tài)容器的強大工具。有無數(shù)的文章都在討論和比較Docker、Kubernetes 以及Mesos。如果你是初學者，那么你可能會認為這三個開源項目正為了稱霸容器界而殊死搏斗。雖然這三種技術都使得使用容器部署、管理和伸縮應用成為可能，但實際上它們各自解決了不同...
摘要：重新認識三如果被推遲執(zhí)行的回調(diào)函數(shù)是某個對象的方法，那么該方法中的關鍵字將指向全局環(huán)境，而不是定義時所在的那個對象。 重新認識一 一般，setTimeout函數(shù)接受兩個參數(shù)，第一個參數(shù)func|code是將要推遲執(zhí)行的函數(shù)名或者一段代碼（引擎內(nèi)部使用eval函數(shù)，將字符串轉(zhuǎn)為代碼），第二個參數(shù)delay是推遲執(zhí)行的毫秒數(shù)。但是，setTimeout 還可以添加更多參數(shù)。第二個之后的參數(shù)...
摘要：分布式架構(gòu)實踐負載均衡在網(wǎng)站創(chuàng)立初期，我們一般都使用單臺機器對臺提供集中式服務，但是隨著業(yè)務量越來越大，無論是性能上還是穩(wěn)定性上都有了更大的挑戰(zhàn)。就鹿晗宣布戀情導致微博宕機事件淺談大型網(wǎng)站高可用性架構(gòu)中午吃飯刷著刷著微博發(fā)現(xiàn)微博突然掛了。 分布式架構(gòu)實踐——負載均衡 在網(wǎng)站創(chuàng)立初期，我們一般都使用單臺機器對臺提供集中式服務，但是隨著業(yè)務量越來越大，無論是性能上還是穩(wěn)定性上都有了更大的挑...
閱讀 1638·2021-11-25 09:43
閱讀 2546·2019-08-30 15:54
閱讀 3015·2019-08-30 15:53
閱讀 1156·2019-08-30 15:53
閱讀 799·2019-08-30 15:52
閱讀 2593·2019-08-26 13:36
閱讀 869·2019-08-26 12:16
閱讀 1288·2019-08-26 12:13
