《面試八股文》之Dubbo17卷
微信公眾號(hào)：moon聊技術(shù)
關(guān)注選擇“ 星標(biāo) ”， 重磅干貨，第一 時(shí)間送達(dá)！
[如果你覺得文章對(duì)你有幫助，歡迎關(guān)注，在看，點(diǎn)贊，轉(zhuǎn)發(fā)]
前言
雖然金三銀四過了，但是金九銀十馬上就要到了，還不快快準(zhǔn)備起來？
今天就開啟《面試八股文》系列的第一版-RPC王者Dubbo，moon 在后續(xù)的《面試八股文》系列還將繼續(xù)推出mysql，spring，并發(fā)，redis，kafka，zookeeper等一系列文章。
當(dāng)然大家有什么好的建議也可以通過公眾號(hào)或者個(gè)人微信和我交流。
每天一個(gè)知識(shí)點(diǎn)
不要背，要理解，大家不要夸我內(nèi)卷了
目錄
1.Dubbo是什么？RPC又是什么？
2. Dubbo能做什么？
3.能說下Dubbo的總體的調(diào)用過程嗎？
4.說說Dubbo 支持哪些協(xié)議，每種協(xié)議的應(yīng)用場景和優(yōu)缺點(diǎn)
5.Dubbo中都用到哪些設(shè)計(jì)模式？
6.如果Dubbo中provider提供的服務(wù)由多個(gè)版本怎么辦？
7.服務(wù)暴露的流程是怎么樣的？
8.服務(wù)引用的流程是怎么樣的？
9.Dubbo的注冊中心有哪些？
10.聊聊Dubbo SPI機(jī)制？
11.Dubbo的SPi和JAVA的SPI有什么區(qū)別？
12.有哪些負(fù)載均衡策略？
13.集群容錯(cuò)方式有哪些？
14.說說Dubbo的分層？
15.服務(wù)提供者能實(shí)現(xiàn)失效踢出是什么原理？
16.為什么要通過代理對(duì)象通信？？
17.怎么設(shè)計(jì)一個(gè)RPC框架？
1.Dubbo是什么？RPC又是什么？
Dubbo是一個(gè)分布式服務(wù)框架，致力于提供高性能和透明化的RPC遠(yuǎn)程服務(wù)調(diào)用方案，以及SOA服務(wù)治理方案。
RPC（Remote Procedure Call）—遠(yuǎn)程過程調(diào)用，它是一種通過網(wǎng)絡(luò)從遠(yuǎn)程計(jì)算機(jī)程序上請求服務(wù)，而不需要了解底>層網(wǎng)絡(luò)技術(shù)的協(xié)議。RPC協(xié)議假定某些傳輸協(xié)議的存在，如TCP或UDP，為通信程序之間攜帶信息數(shù)據(jù)。在OSI網(wǎng)絡(luò)>通信模型中，RPC跨越了傳輸層和應(yīng)用層。RPC使得開發(fā)包括網(wǎng)絡(luò)分布式多程序在內(nèi)的應(yīng)用程序更加容易。RPC采用客戶機(jī)/服務(wù)器模式。請求程序就是一個(gè)客戶機(jī)，而服務(wù)提供程序就是一個(gè)服務(wù)器。首先，客戶機(jī)調(diào)用進(jìn)程發(fā)>送一個(gè)有進(jìn)程參數(shù)的調(diào)用信息到服務(wù)進(jìn)程，然后等待應(yīng)答信息。在服務(wù)器端，進(jìn)程保持睡眠狀態(tài)直到調(diào)用信息到達(dá)為>止。當(dāng)一個(gè)調(diào)用信息到達(dá)，服務(wù)器獲得進(jìn)程參數(shù)，計(jì)算結(jié)果，發(fā)送答復(fù)信息，然后等待下一個(gè)調(diào)用信息，最后，客戶>端調(diào)用進(jìn)程接收答復(fù)信息，獲得進(jìn)程結(jié)果，然后調(diào)用執(zhí)行繼續(xù)進(jìn)行。有多種 RPC模式和執(zhí)行。
我們用一種通俗易懂的語言解釋它，遠(yuǎn)程調(diào)用就是本地機(jī)器調(diào)用遠(yuǎn)程機(jī)器的一個(gè)方法，遠(yuǎn)程機(jī)器返回結(jié)果的過程。
為什么要這么做？
主要原因是由于單臺(tái)服務(wù)的性能已經(jīng)無法滿足我們了，在這個(gè)流量劇增的時(shí)代，只有多臺(tái)服務(wù)器才能支撐起來現(xiàn)有的用戶體系，
而在這種體系下，服務(wù)越來越多，逐漸演化出了現(xiàn)在這種微服務(wù)化的RPC框架。
2. Dubbo能做什么？
Dubbo的核心功能主要包含:
遠(yuǎn)程通訊:dubbo-remoting模塊， 提供對(duì)多種基于長連接的NIO框架抽象封裝，包括多種線程模型，序列化，以及“請求-響應(yīng)”模式的信息交換方式。 集群容錯(cuò): 提供基于接口方法的透明遠(yuǎn)程過程調(diào)用，包括多協(xié)議支持，以及軟負(fù)載均衡，失敗容錯(cuò)，地址路由，動(dòng)態(tài)配置等集群支持。 自動(dòng)發(fā)現(xiàn): 基于注冊中心目錄服務(wù)，使服務(wù)消費(fèi)方能動(dòng)態(tài)的查找服務(wù)提供方，使地址透明，使服務(wù)提供方可以平滑增加或減少機(jī)器。
3.能說下Dubbo的總體的調(diào)用過程嗎？
調(diào)用過程圖：
1.Proxy持有一個(gè)Invoker對(duì)象，使用Invoker調(diào)用 2.之后通過Cluster進(jìn)行負(fù)載容錯(cuò)，失敗重試 3.調(diào)用Directory獲取遠(yuǎn)程服務(wù)的Invoker列表 4.負(fù)載均衡 用戶配置了路由規(guī)則，則根據(jù)路由規(guī)則過濾獲取到的Invoker列表 用戶沒有配置路由規(guī)則或配置路由后還有很多節(jié)點(diǎn)，則使用LoadBalance方法做負(fù)載均衡，選用一個(gè)可以調(diào)用的Invoker 5.經(jīng)過一個(gè)一個(gè)過濾器鏈，通常是處理上下文、限流、計(jì)數(shù)等。 6.會(huì)使用Client做數(shù)據(jù)傳輸 7.私有化協(xié)議的構(gòu)造(Codec) 8.進(jìn)行序列化 9.服務(wù)端收到這個(gè)Request請求，將其分配到ThreadPool中進(jìn)行處理 10.Server來處理這些Request 11.根據(jù)請求查找對(duì)應(yīng)的Exporter 12.之后經(jīng)過一個(gè)服務(wù)提供者端的過濾器鏈 13.然后找到接口實(shí)現(xiàn)并真正的調(diào)用，將請求結(jié)果返回
4.說說Dubbo 支持哪些協(xié)議，每種協(xié)議的應(yīng)用場景和優(yōu)缺點(diǎn)
1.dubbo 單一長連接和 NIO 異步通訊，適合大并發(fā)小數(shù)據(jù)量的服務(wù)調(diào)用，以及消費(fèi)者遠(yuǎn)大于提供者。傳輸協(xié)議 TCP，異步，Hessian 序列化
2.rmi ?采用 JDK 標(biāo)準(zhǔn)的 rmi 協(xié)議實(shí)現(xiàn)，傳輸參數(shù)和返回參數(shù)對(duì)象需要實(shí)現(xiàn)Serializable 接口，使用 java 標(biāo)準(zhǔn)序列化機(jī)制，使用阻塞式短連接，傳輸數(shù)據(jù)包大小混合，消費(fèi)者和提供者個(gè)數(shù)差不多，可傳文件，傳輸協(xié)議 TCP。多個(gè)短連接，TCP 協(xié)議傳輸，同步傳輸，適用常規(guī)的遠(yuǎn)程服務(wù)調(diào)用和 rmi 互 操作。在依賴低版本的 Common-Collections 包，java 序列化存在安全漏洞
3.webservice 基于 WebService 的遠(yuǎn)程調(diào)用協(xié)議，集成 CXF 實(shí)現(xiàn)，提供和原生 WebService 的互操作。多個(gè)短連接，基于 HTTP 傳輸，同步傳輸，適用系統(tǒng)集成和跨語言調(diào)用；
4.http ?基于 Http 表單提交的遠(yuǎn)程調(diào)用協(xié)議，使用 Spring 的 HttpInvoke 實(shí) 現(xiàn)。多個(gè)短連接，傳輸協(xié)議 HTTP，傳入?yún)?shù)大小混合，提供者個(gè)數(shù)多于消 費(fèi)者，需要給應(yīng)用程序和瀏覽器 JS 調(diào)用
5.hessian ?集成 Hessian 服務(wù)，基于 HTTP 通訊，采用 Servlet 暴露服務(wù)，Dubbo 內(nèi)嵌 Jetty 作為服務(wù)器時(shí)默認(rèn)實(shí)現(xiàn)，提供與 Hession 服務(wù)互操作。多個(gè)短連接，同步 HTTP 傳輸，Hessian 序列化，傳入?yún)?shù)較大，提供者大于消費(fèi)者，提供者壓力較大，可傳文件；
6.memcache ?基于 memcached 實(shí)現(xiàn)的 RPC 協(xié)議
7.redis 基于 redis 實(shí)現(xiàn)的 RPC 協(xié)議
5.Dubbo中都用到哪些設(shè)計(jì)模式？
責(zé)任鏈模式:
責(zé)任鏈模式在Dubbo中發(fā)揮的作用舉足輕重，就像是Dubbo框架的骨架。Dubbo的調(diào)用鏈組織是用責(zé)任鏈模式串連起來的。責(zé)任鏈中的每個(gè)節(jié)點(diǎn)實(shí)現(xiàn)Filter接口，然后由ProtocolFilterWrapper，將所有Filter串連起來。Dubbo的許多功能都是通過Filter擴(kuò)展實(shí)現(xiàn)的，比如監(jiān)控、日志、緩存、安全、telnet以及RPC本身都是。
觀察者模式:
Dubbo中使用觀察者模式最典型的例子是RegistryService。消費(fèi)者在初始化的時(shí)候回調(diào)用subscribe方法，注冊一個(gè)觀察者，如果觀察者引用的服務(wù)地址列表發(fā)生改變，就會(huì)通過NotifyListener通知消費(fèi)者。此外，Dubbo的InvokerListener、ExporterListener 也實(shí)現(xiàn)了觀察者模式，只要實(shí)現(xiàn)該接口，并注冊，就可以接收到consumer端調(diào)用refer和provider端調(diào)用export的通知。
修飾器模式:
Dubbo中還大量用到了修飾器模式。比如ProtocolFilterWrapper類是對(duì)Protocol類的修飾。在export和refer方法中，配合責(zé)任鏈模式，把Filter組裝成責(zé)任鏈，實(shí)現(xiàn)對(duì)Protocol功能的修飾。其他還有ProtocolListenerWrapper、 ListenerInvokerWrapper、InvokerWrapper等。
工廠方法模式:
CacheFactory的實(shí)現(xiàn)采用的是工廠方法模式。CacheFactory接口定義getCache方法，然后定義一個(gè)AbstractCacheFactory抽象類實(shí)現(xiàn)CacheFactory，并將實(shí)際創(chuàng)建cache的createCache方法分離出來，并設(shè)置為抽象方法。這樣具體cache的創(chuàng)建工作就留給具體的子類去完成。
抽象工廠模式:
ProxyFactory及其子類是Dubbo中使用抽象工廠模式的典型例子。ProxyFactory提供兩個(gè)方法，分別用來生產(chǎn)Proxy和Invoker（這兩個(gè)方法簽名看起來有些矛盾，因?yàn)間etProxy方法需要傳入一個(gè)Invoker對(duì)象，而getInvoker方法需要傳入一個(gè)Proxy對(duì)象，看起來會(huì)形成循環(huán)依賴，但其實(shí)兩個(gè)方式使用的場景不一樣）。AbstractProxyFactory實(shí)現(xiàn)了ProxyFactory接口，作為具體實(shí)現(xiàn)類的抽象父類。然后定義了JdkProxyFactory和JavassistProxyFactory兩個(gè)具體類，分別用來生產(chǎn)基于jdk代理機(jī)制和基于javassist代理機(jī)制的Proxy和Invoker。
適配器模式:
為了讓用戶根據(jù)自己的需求選擇日志組件，Dubbo自定義了自己的Logger接口，并為常見的日志組件（包括jcl, jdk, log4j, slf4j）提供相應(yīng)的適配器。并且利用簡單工廠模式提供一個(gè)LoggerFactory，客戶可以創(chuàng)建抽象的Dubbo自定義Logger，而無需關(guān)心實(shí)際使用的日志組件類型。在LoggerFactory初始化時(shí)，客戶通過設(shè)置系統(tǒng)變量的方式選擇自己所用的日志組件，這樣提供了很大的靈活性。
代理模式:
Dubbo consumer使用Proxy類創(chuàng)建遠(yuǎn)程服務(wù)的本地代理，本地代理實(shí)現(xiàn)和遠(yuǎn)程服務(wù)一樣的接口，并且屏蔽了網(wǎng)絡(luò)通信的細(xì)節(jié)，使得用戶在使用本地代理的時(shí)候，感覺和使用本地服務(wù)一樣。
6.如果Dubbo中provider提供的服務(wù)由多個(gè)版本怎么辦？
可以直接通過Dubbo配置中的version版本來控制多個(gè)版本即可。
比如：
"com.xxxx.rent.service.IDemoService"?ref="iDemoServiceFirst"?version="1.0.0"/>
"com.xxxx.rent.service.IDemoService"?ref="iDemoServiceSecond"?version="1.0.1"/>
老版本 version=1.0.0, 新版本version=1.0.1
7.服務(wù)暴露的流程是怎么樣的？
1.通過ServiceConfig解析標(biāo)簽，創(chuàng)建dubbo標(biāo)簽解析器來解析dubbo的標(biāo)簽，容器創(chuàng)建完成之后，觸發(fā)ContextRefreshEvent事件回調(diào)開始暴露服務(wù)
2.通過proxyFactory.getInvoker方法，并利用javassist或DdkProxyFactory來進(jìn)行動(dòng)態(tài)代理，將服務(wù)暴露接口封裝成invoker對(duì)象，里面包含了需要執(zhí)行的方法的對(duì)象信息和具體的URL地址。
3.再通過DubboProtocol的實(shí)現(xiàn)把包裝后的invoker轉(zhuǎn)換成exporter，
4.然后啟動(dòng)服務(wù)器server，監(jiān)聽端口
5.最后RegistryProtocol保存URL地址和invoker的映射關(guān)系，同時(shí)注冊到服務(wù)中心
8.服務(wù)引用的流程是怎么樣的？
1.首先客戶端根據(jù)config文件信息從注冊中心訂閱服務(wù)，首次會(huì)全量緩存到本地，后續(xù)的更新會(huì)監(jiān)聽動(dòng)態(tài)更新到本地。
2.之后DubboProtocol根據(jù)provider的地址和接口信息連接到服務(wù)端server，開啟客戶端client，然后創(chuàng)建invoker
3.之后通過invoker為服務(wù)接口生成代理對(duì)象，這個(gè)代理對(duì)象用于遠(yuǎn)程調(diào)用provider，至此完成了服務(wù)引用
9.Dubbo的注冊中心有哪些？
Zookeeper、Redis、Multicast、Simple 等都可以作為Dubbo的注冊中心
10.聊聊Dubbo SPI機(jī)制？
SPI(Service Provider Interface)，是一種服務(wù)發(fā)現(xiàn)機(jī)制，其實(shí)就是將結(jié)構(gòu)的實(shí)現(xiàn)類寫入配置當(dāng)中，在服務(wù)加載的時(shí)候?qū)⑴渲梦募?dú)處，加載實(shí)現(xiàn)類，這樣就可以在運(yùn)行的時(shí)候，動(dòng)態(tài)的幫助接口替換實(shí)現(xiàn)類。
Dubbo的SPI其實(shí)是對(duì)java的SPI進(jìn)行了一種增強(qiáng),可以按需加載實(shí)現(xiàn)類之外，增加了 IOC 和 AOP 的特性，還有自適應(yīng)擴(kuò)展機(jī)制。
SPI在dubbo應(yīng)用很多，包括協(xié)議擴(kuò)展、集群擴(kuò)展、路由擴(kuò)展、序列化擴(kuò)展等等。
Dubbo對(duì)于文件目錄的配置分為了三類。
1.META-INF/services/ 目錄：該目錄下的 SPI 配置文件是為了用來兼容 Java SPI 。 2.META-INF/dubbo/ 目錄：該目錄存放用戶自定義的 SPI 配置文件。
key=com.xxx.xxx
3.META-INF/dubbo/internal/ 目錄：該目錄存放 Dubbo 內(nèi)部使用的 SPI 配置文件。
11.Dubbo的SPi和JAVA的SPI有什么區(qū)別？
Java Spi
Java SPI 在查找擴(kuò)展實(shí)現(xiàn)類的時(shí)候遍歷 SPI 的配置文件并且將實(shí)現(xiàn)類全部實(shí)例化
Dubbo Spi
1，對(duì) Dubbo 進(jìn)行擴(kuò)展，不需要改動(dòng) Dubbo 的源碼 2，延遲加載，可以一次只加載自己想要加載的擴(kuò)展實(shí)現(xiàn)。 3，增加了對(duì)擴(kuò)展點(diǎn) IOC 和 AOP 的支持，一個(gè)擴(kuò)展點(diǎn)可以直接 setter 注入其它擴(kuò)展點(diǎn)。 4，Dubbo 的擴(kuò)展機(jī)制能很好的支持第三方 IoC 容器，默認(rèn)支持 Spring Bean。
12.有哪些負(fù)載均衡策略？
1.加權(quán)隨機(jī)：比如我們有三臺(tái)服務(wù)器[A, B, C]，給他們設(shè)置權(quán)重為[4, 5, 6]，然后講這三個(gè)數(shù)平鋪在水平線上,和為15。
然后在15以內(nèi)生成一個(gè)隨機(jī)數(shù)，0～4是服務(wù)器A，4～9是服務(wù)器B，9～15是服務(wù)器C
2.最小活躍數(shù)：每個(gè)服務(wù)提供者對(duì)應(yīng)一個(gè)活躍數(shù) active，初始情況下，所有服務(wù)提供者活躍數(shù)均為0。每收到一個(gè)請求，活躍數(shù)加1，完成請求后則將活躍數(shù)減1。在服務(wù)運(yùn)行一段時(shí)間后，性能好的服務(wù)提供者處理請求的速度更快，因此活躍數(shù)下降的也越快，此時(shí)這樣的服務(wù)提供者能夠優(yōu)先獲取到新的服務(wù)請求。
3.一致性hash：
首先求出memcached服務(wù)器（節(jié)點(diǎn)）的哈希值，并將其配置到0～2的32次方的圓（continuum）上。 然后采用同樣的方法求出存儲(chǔ)數(shù)據(jù)的鍵的哈希值，并映射到相同的圓上。 然后從數(shù)據(jù)映射到的位置開始順時(shí)針查找，將數(shù)據(jù)保存到找到的第一個(gè)服務(wù)器上。如果超過2的32次方仍然找不到服務(wù)器，就會(huì)保存到第一臺(tái)memcached服務(wù)器上。
4.加權(quán)輪詢：比如我們有三臺(tái)服務(wù)器[A, B, C]，給他們設(shè)置權(quán)重為[4, 5, 6]，那么假如總共有15次請求，那么會(huì)有4次落在A服務(wù)器，5次落在B服務(wù)器，6次落在C服務(wù)器。
13.集群容錯(cuò)方式有哪些？
1.Failover Cluster失敗自動(dòng)切換：dubbo的默認(rèn)容錯(cuò)方案，當(dāng)調(diào)用失敗時(shí)自動(dòng)切換到其他可用的節(jié)點(diǎn)，具體的重試次數(shù)和間隔時(shí)間可用通過引用服務(wù)的時(shí)候配置，默認(rèn)重試次數(shù)為1是只調(diào)用一次。
2.Failback Cluster失敗自動(dòng)恢復(fù)：在調(diào)用失敗，記錄日志和調(diào)用信息，然后返回空結(jié)果給consumer，并且通過定時(shí)任務(wù)每隔5秒對(duì)失敗的調(diào)用進(jìn)行重試
3.Failfast Cluster快速失敗：只會(huì)調(diào)用一次，失敗后立刻拋出異常
4.Failsafe Cluster失敗安全：調(diào)用出現(xiàn)異常，記錄日志不拋出，返回空結(jié)果
5.Forking Cluster并行調(diào)用多個(gè)服務(wù)提供者：通過線程池創(chuàng)建多個(gè)線程，并發(fā)調(diào)用多個(gè)provider，結(jié)果保存到阻塞隊(duì)列，只要有一個(gè)provider成功返回了結(jié)果，就會(huì)立刻返回結(jié)果
6.Broadcast Cluster廣播模式：逐個(gè)調(diào)用每個(gè)provider，如果其中一臺(tái)報(bào)錯(cuò)，在循環(huán)調(diào)用結(jié)束后，拋出異常。
14.說說Dubbo的分層？
分層圖：
從大的范圍來說，dubbo分為三層
business業(yè)務(wù)邏輯層由我們自己來提供接口和實(shí)現(xiàn)還有一些配置信息 RPC層就是真正的RPC調(diào)用的核心層，封裝整個(gè)RPC的調(diào)用過程、負(fù)載均衡、集群容錯(cuò)、代理 remoting則是對(duì)網(wǎng)絡(luò)傳輸協(xié)議和數(shù)據(jù)轉(zhuǎn)換的封裝。
Service和Config兩層可以認(rèn)為是API層，主要提供給API使用者，使用者只需要配置和完成業(yè)務(wù)代碼就可以了。
后面所有的層級(jí)是SPI層，主 要提供給擴(kuò)展者使用主要是用來做Dubbo的二次開發(fā)擴(kuò)展功能。
再劃分到更細(xì)的層面，就是圖中的10層模式。
15.服務(wù)提供者能實(shí)現(xiàn)失效踢出是什么原理？
服務(wù)失效踢出基于Zookeeper的臨時(shí)節(jié)點(diǎn)原理。
Zookeeper中節(jié)點(diǎn)是有生命周期的，具體的生命周期取決于節(jié)點(diǎn)的類型，節(jié)點(diǎn)主要分為持久節(jié)點(diǎn)(Persistent)和臨時(shí)節(jié)點(diǎn)(Ephemeral) 。
16.為什么要通過代理對(duì)象通信？？
其實(shí)主要就是為了將調(diào)用細(xì)節(jié)封裝起來，將調(diào)用遠(yuǎn)程方法變得和調(diào)用本地方法一樣簡單，還可以做一些其他方面的增強(qiáng)，比如負(fù)載均衡，容錯(cuò)機(jī)制，過濾操作，調(diào)用數(shù)據(jù)的統(tǒng)計(jì)。
17.怎么設(shè)計(jì)一個(gè)RPC框架？
關(guān)于這個(gè)問題，其實(shí)核心考察點(diǎn)就是你對(duì)于RPC框架的理解，一個(gè)成熟的RPC框架可以完成哪些功能，其實(shí)當(dāng)我們看過一兩個(gè)RPC框架后，就可以對(duì)這個(gè)問題回答個(gè)七七八八了，我們來舉個(gè)例子。
1.首先我們得需要一個(gè)注冊中心，去管理消費(fèi)者和提供者的節(jié)點(diǎn)信息，這樣才會(huì)有消費(fèi)者和提供才可以去訂閱服務(wù)，注冊服務(wù)。
2.當(dāng)有了注冊中心后，可能會(huì)有很多個(gè)provider節(jié)點(diǎn)，那么我們肯定會(huì)有一個(gè)負(fù)載均衡模塊來負(fù)責(zé)節(jié)點(diǎn)的調(diào)用，至于用戶指定路由規(guī)則可以使一個(gè)額外的優(yōu)化點(diǎn)。
3.具體的調(diào)用肯定會(huì)需要牽扯到通信協(xié)議，所以需要一個(gè)模塊來對(duì)通信協(xié)議進(jìn)行封裝，網(wǎng)絡(luò)傳輸還要考慮序列化。
4.當(dāng)調(diào)用失敗后怎么去處理？所以我們還需要一個(gè)容錯(cuò)模塊，來負(fù)責(zé)失敗情況的處理。
5.其實(shí)做完這些一個(gè)基礎(chǔ)的模型就已經(jīng)搭建好了，我們還可以有更多的優(yōu)化點(diǎn)，比如一些請求數(shù)據(jù)的監(jiān)控，配置信息的處理，日志信息的處理等等。
這其實(shí)就是一個(gè)比較基本的RPC框架的大體思路，大家有沒有g(shù)et到？
往期推薦
確定不勾搭一下moon嗎？
玩玩技術(shù)，聊聊人生，看看生活，搞搞理想!
一起來吐槽職場吧~