概述
- 前言
- 什么是微服務(wù)
- 微服務(wù)的特征與優(yōu)勢(shì)
- 微服務(wù)的不足
- 微服務(wù)通信方式
- 我應(yīng)該使用微服務(wù)嗎像吻？
- 后記
前言
大半年前战惊，我第一次聽說【微服務(wù)】這個(gè)詞溯职，當(dāng)時(shí)由于好奇心，就 Google 了一下這個(gè)詞胳施，從此埋下了一顆學(xué)習(xí)微服務(wù)的心。在前半年的時(shí)間里因?yàn)槊χǎ猿椴怀鐾暾臅r(shí)間塊來學(xué)習(xí)微服務(wù)舞肆。但都有使用閑碎的時(shí)間來看相關(guān)的概念與架構(gòu)。最近總算是有點(diǎn)時(shí)間了博杖，我覺得光看概念是沒有用的椿胯，要真真實(shí)實(shí)地實(shí)踐一下，才能真正學(xué)到東西剃根。這才有了這篇文章（后面會(huì)有系列文章）哩盲。
什么是微服務(wù)
我們就以微信為栗子，來解釋一下微服務(wù)。首先假設(shè)你要做一款簡(jiǎn)化版的微信產(chǎn)品廉油，他只有如下幾個(gè)功能惠险。那么你的初期系統(tǒng)設(shè)計(jì)應(yīng)該是這樣的：
隨著時(shí)間的遷移，我們?nèi)兆觼淼搅?2019.01.01 00:00 跨年抒线，此時(shí)此刻班巩，很多人都在發(fā)朋友圈。朋友圈接口訪問量很大很大很大嘶炭，服務(wù)器訪問峰值瞬間沖頂抱慌，那么我們可以開始做集群操作。也就是整一個(gè)服務(wù)器做集群操作眨猎。那么我們的注冊(cè)登錄接口抑进、支付接口、聊天接口也有了一個(gè)復(fù)制集宵呛，在此時(shí)此刻這幾個(gè)接口是比較雞肋的单匣，那我們能不能只將朋友圈的接口做集群呢？答案當(dāng)然是可以的宝穗，且看下圖 -- 微服務(wù)架構(gòu)
那么當(dāng)我們微服務(wù)架構(gòu)遇到 2019.01.01 00:00 跨年户秤，會(huì)怎么樣呢？
直接水平擴(kuò)展朋友圈服務(wù)逮矛，如下圖鸡号，峰值壓力有所緩解。
然而在各個(gè)功能拆解成一個(gè)個(gè)的服務(wù)之后须鼎，由客戶端直接訪問各個(gè)微服務(wù)鲸伴，這樣就直接將我們的服務(wù)暴露了出來，客戶端也需要定制相應(yīng)的訪問策略晋控。這樣的設(shè)計(jì)還是沒有那么友好汞窗。那么，我們能不能將所有微服務(wù)統(tǒng)一到一起呢赡译？且看下圖：
在這張示例圖中仲吏，多了一個(gè) APIGateway ，那 API 網(wǎng)關(guān)是用來干嘛的呢蝌焚？
一般情況下 API 網(wǎng)關(guān)有一下任務(wù)：路由裹唆，安全，限流只洒，緩存许帐，日志，監(jiān)控毕谴，重試成畦，熔斷等距芬，然后服務(wù)層就純粹的做業(yè)務(wù)，也能夠很好的保證業(yè)務(wù)代碼的干凈羡鸥，不用關(guān)心安全蔑穴，壓力等方面的問題。
當(dāng)然惧浴，以上示例圖只是一個(gè)小小的演示存和，真實(shí)的使用中，要比這個(gè)復(fù)雜得多衷旅，這里只是先拋出概念捐腿，供大家理解。
維基百科對(duì)微服務(wù)的定義:
微服務(wù) (Microservices) 是一種軟件架構(gòu)風(fēng)格柿顶，它是以專注于單一責(zé)任與功能的小型功能區(qū)塊 (Small Building Blocks) 為基礎(chǔ)茄袖，利用模組化的方式組合出復(fù)雜的大型應(yīng)用程序，各功能區(qū)塊使用與語言無關(guān) (Language-Independent/Language agnostic) 的 API 集相互通訊嘁锯。
微服務(wù)的特征與優(yōu)勢(shì)
微服務(wù)特征：
- 單一職責(zé)宪祥；
- 輕量級(jí)的通信；
- 隔離性家乘，運(yùn)行在自己的進(jìn)程中蝗羊，不會(huì)相互干擾；
- 有自己的數(shù)據(jù)仁锯，數(shù)據(jù)的獨(dú)立性耀找，每個(gè)微服務(wù)都有自己的數(shù)據(jù)庫；
- 技術(shù)的多樣性业崖，選用適合的技術(shù)做合適的事野芒；
一個(gè)微服務(wù)就負(fù)責(zé)某一個(gè)職責(zé)，就像朋友圈服務(wù)双炕，它就只負(fù)責(zé)朋友圈的【增刪查】功能狞悲，與其他服務(wù)獨(dú)立開來
微服務(wù)的優(yōu)勢(shì)：
-
獨(dú)立性
每個(gè)微服務(wù)的構(gòu)建、部署妇斤、擴(kuò)容效诅、縮容、數(shù)據(jù)庫都是獨(dú)立的趟济。數(shù)據(jù)庫表修改時(shí)，互補(bǔ)影響咽笼。 -
敏捷性
功能單一顷编、可快速添加新需求 -
技術(shù)棧靈活
可以發(fā)揮不同語言的優(yōu)勢(shì)，例如：用 python 來爬數(shù)據(jù)剑刑，nodejs 來處理 io 流 -
高效團(tuán)隊(duì)
可以分發(fā)給不同的團(tuán)隊(duì)進(jìn)行開發(fā)
微服務(wù)的不足
- 額外的工作媳纬；
- 數(shù)據(jù)一致性双肤；
- 溝通成本；
需要額外工作钮惠，例如：服務(wù)的拆分（即如何拆分微服務(wù)茅糜，哪些服務(wù)應(yīng)該拆到一起）、服務(wù)注冊(cè)素挽、服務(wù)發(fā)現(xiàn)蔑赘、微服務(wù)間的通信。每個(gè)微服務(wù)都持有獨(dú)立的數(shù)據(jù)庫预明，無法做到數(shù)據(jù)強(qiáng)一致性缩赛，只能做到最終結(jié)果一致性。做微服務(wù)也會(huì)增加團(tuán)隊(duì)的溝通成本撰糠。
微服務(wù)通信方式
微服務(wù)可以使用兩種基本消息傳遞模式 -- 同步與異步消息傳遞酥馍，來與其他微服務(wù)通信。
同步通信阅酪。 在此模式下旨袒，一個(gè)服務(wù)使用 HTTP 或 RPC（Remote Procedure Call，翻譯過來為“遠(yuǎn)程過程調(diào)用”） 框架等協(xié)議調(diào)用另一個(gè)服務(wù)公開的 API术辐。 此選項(xiàng)之所以稱作同步消息傳遞模式砚尽，是因?yàn)檎{(diào)用方需要等待接收方返回的響應(yīng)。比較通用的 RPC 框架有：gRPC（Google）术吗、Thrift（Apache）
異步消息傳遞尉辑。 在此模式下，服務(wù)可以在不等待回應(yīng)的情況下發(fā)送消息较屿，然后一個(gè)或多個(gè)服務(wù)以異步方式處理該消息隧魄。比較流行的消息隊(duì)列有：RabbitMQ、ZeroMQ隘蝎、Kafka购啄、ActiveMQ
至于具體怎么通信，后面會(huì)有詳細(xì)的分享嘱么。本文只是先介紹微服務(wù)如何通信狮含。
我們應(yīng)該使用微服務(wù)嗎？
微服務(wù)已經(jīng)成為一種熱門的架構(gòu)模式了曼振，打開各大技術(shù)類網(wǎng)站幾乎都少不了微服務(wù)的身影几迄。但微服務(wù)真的適合我們當(dāng)下的用戶規(guī)模與公司級(jí)別嗎？這個(gè)問題冰评，其實(shí)也沒有比較統(tǒng)一的答案映胁。在我看來，其實(shí)大部分小公司是用不到微服務(wù)的甲雅，因?yàn)槠洳蛔氵h(yuǎn)大于其優(yōu)勢(shì)解孙，單體應(yīng)用做好優(yōu)化坑填、數(shù)據(jù)庫讀寫分離、集群弛姜、負(fù)載均衡脐瑰，就能應(yīng)對(duì)日常的流量。當(dāng)你以上的優(yōu)化都做了廷臼，還是撐不住壓力的話苍在，就可以考慮微服務(wù)了。當(dāng)然中剩，服務(wù)架構(gòu)選型還是看不同情況和公司意志的忌穿，如果有必要做跨語言等其他需求，那就做微服務(wù)的结啼。
后記
最后掠剑，拋開業(yè)務(wù)上的原因，我們作為技術(shù)人也需要學(xué)習(xí)微服務(wù)相關(guān)的技術(shù)郊愧，不能局限于用不上就不學(xué)習(xí)朴译。在當(dāng)下大環(huán)境下，儲(chǔ)備多一點(diǎn)知識(shí)属铁，提高自身競(jìng)爭(zhēng)力總是沒有壞處的眠寿。
個(gè)人的知識(shí)儲(chǔ)備總是有限的，如有錯(cuò)誤的地方焦蘑，還請(qǐng)大佬斧正盯拱。點(diǎn)擊閱讀原文，鏈接到我的知乎例嘱，我會(huì)在知乎上對(duì)文章錯(cuò)誤的地方進(jìn)行修改狡逢。
本篇文章首發(fā)于公眾號(hào)「zone7」，關(guān)注公眾號(hào)獲取最新推文拼卵。
