基於微服務,打造共享開發平台

2021-09-17 19:01:41 字數 4833 閱讀 7683

於人,隨行付 cto \u0026amp; 研發中心總經理,黑少·微服務商店創始人,tgo 鯤鵬會成員,中國人民大學emba,全棧工程師,擁有14年開發經驗,11年技術管理經驗。

於人:首先是社會發展趨勢,眼下我們整處於不確定性時代,外界環境變化非常快,因此企業需要在系統上快速響應這些變化。微服務最大的特點,就是能夠快速地響應業務變化。

第二,微服務的特點是功能和業務的有機結合,功能是載體,業務是靈魂,兩者疊加構成了乙個具備價值很高的產品。

第三,其他方式,比如saas方式或者paas都無法解決to b的定製需求,很多saas平台被定製化需求搞得很頭疼,這也是很多to b的saas企業的困境。但是,微服務正好能解決企業的定製化痛點。隨行付本身就是b端企業,黑少團隊有著多年的b端應用經驗,我們在實踐中就會發現其他模式的短板,當然也有長處。

infoq:您認為企業在什麼情況下適合做微服務?如果做微服務的話有哪些難點?

於人:企業快速發展期最需要微服務,乙個快速發展、快速成長的企業,業務變化一定非常快,並且時間成本非常高,而微服務模式可以快速地響應各種變化。

infoq:企業應該怎麼做微服務?應該如何分配資源、尤其是人力資源,來有效提公升開發的效率?

於人:微服務的理念源自2023年誕生的康威定律,它認為系統要與企業組織結構相匹配。反過來說,企業如果想做微服務,那麼它的組織結構也要盡量適用於微服務,比方說敏捷。實施微服務,其實是一整套管理體系的公升級,切換成微服務以後,企業的整體開發效率會有乙個質的變化。隨行付核心架構切換為微服務模式以後,人均開發效能提公升了一倍。

infoq:當初是什麼原因促成了黑少微服務商店的建立?為什麼要建立這個微服務商店?這個商店的定位是怎麼樣的?

於人:這還真是個i can i up的事(笑)。黑少微服務商店是乙個微服務\u0026amp;原始碼的交易平台,建立它其實是從我們的實際需求出發。我們有很多業務在快速發生變化,變化產生需求,可這些需求極大概率在市面有其他團隊已經做過了,如果乙個公開透明的交易渠道,就意味著每個團隊產生需求的時候,都要自己再做一遍,開發行業就只能處於重複造輪子的低效狀態。需求積壓只會越來越大、越來越多,開發者個體就必須把時間精力投入在低效的重複勞作之中。如果有乙個地方,能讓我快速購買這些業務模組,根據我自己的需求稍微調整一下,立刻就能匹配到業務上,那我們企業地增長一定會更快。

我們常年服務於b端企業,我們確信這類需求客觀存在,我們也試圖求助於paas模式或者saas平台,但是購買之後發現,它們提供的服務跟我們的業務匹配度差強人意。最終,經過這幾年微服務技術的積累,我們發現微服務是一種非常適合共享交易的開發模式,它既包含功能又包含業務,對於企業而言,業務是具有實際使用價值的元素,因此我們判斷,微服務具有足夠的交易價值。

站在我們自己的角度,我們就是b端企業使用者,我們有這個需要,而市場上又沒有太合適的解決方案,那就自己下場試一試,嘗試推出一套解決方案。

infoq:和其他同品類的一些平台,比如說spring和阿里提供的類似服務相比,黑少微服務商店提供的產品和服務有什麼優勢和特點?開發者如果選擇黑少的話,他們可以獲得什麼樣的好處?

於人:如前所述,我們一直聚焦於業務,業務既是微服務商店的起點,也是終點。您提到的那幾家平台基本上是底層的技術解決方案,還是以技術為主。剛才提到過,微服務妙就妙在業務和技術的結合,而隨行付更擅長業務,我們服務了幾百萬家中小微企業,我們知道to b應用的企業訴求是什麼,知道真正的業務需要什麼。在to b的實用性這個維度上講,我們是有一定差異化的。

infoq:黑少微服務商店,這個名字挺有特色的,您說微服務商店裡面用到了一些黑科技,這些黑科技都有哪些?

於人:隨行付使用微服務架構將近3年,積累了一些實用的技術工具,比如已經貢獻出去的一些開源元件,比如基於適用性的微服務開發平台公升級等等,還包括我們為了開發人員量身訂作的一些自動化開發功能,自動化運維、自動化開發、自動化容器等等。

另外,我們的人工智慧測試明年也會上線,現在已經著手在做,方案已經落地,論證環節已經通過,明年就會跟大家見面。

下一步可能有點遠,我們還要在人工智慧開發這個領域去發力。總之就是通過一些人工智慧的手段、科技的手段,幫助開發者更高效地完成自己開發創新,幫助企業更迅速地解決發展過程中遇到的問題。

infoq:您在建立黑少微服務商店的過程中,有沒有什麼讓您非常印象深刻困難或困境?黑少又是如何克服這些困難的?

於人:業務和技術上都遇到過困難。首先說業務,黑少微服務商店的核心模式,其實是爭取盡可能多的減少軟體開發行業內的重複勞動,去重是商店模式的核心,通過去重降低應用開發成本,提公升開發效率,釋放生產力價值,讓開發者們有更多的精力投入到創新型工作之中。去重是整個軟體開發行業的共同目標,大家都在試探各種手段,像paas平台,或者是眾包模式等等,可到底應該選哪條路?最初我也非常迷茫,於是跟大量的技術管理者溝通,也見了很多投資人。大家都給了我很多有效建議,尤其是一位紅杉資本非常著名的to b投資人,幫助清理了許多不太靠譜的雜念。前一陣劉潤老師有一篇文章刷屏了,to c和to b之間區別的文章,那就是我諮詢完劉潤老師以後,他總結出來的。大家一起幫助我把這個想法收束到微服務商店這個點上。

infoq:有高人指點,事情就變得容易很多。

於人:高人幫我做減法。收束到微服務商店模式之後反推,發現一切邏輯都能推通。這是業務方面遇到的困惑。

在技術上,肯定也有難點,微服務、微服務商店都是新興事物。微服務我們還算用得早,三年使用經驗,團隊內有微服務領域的專家,積累了很多東西。最開始,我們並不想自己做一套開發平台,我們一直聚焦做商店,但是商店一定要配套一套開發平台,幫助大家快速開發、在商店上完成組裝。

最初我們是想採購一套平台,在市面上找了很多家,發現確實沒有能完全滿足我們需求的。沒辦法,就自己做了,但是這套開發平台完全是不以盈利為目的,給大家免費使用。之前隨行付的發展也得到過開源社群的大量幫助,所以現在想回饋社會、回饋開源社群。

infoq:關於微服務,黑少有很多這方面的經驗,也正是這些經驗奠定了黑少打造微服務平台的基礎。以黑少的經驗來看,在微服務開發的過程中開發者應該如何進行架構的選型,黑少有哪些經驗可以分享?

於人:我們是由以前以dubbo作為通訊方案的一套架構轉到springcloud,主要的原因是springcloud現在整體的生態比較完整,dubbo某一部分做得已經挺好的了,但是它在廣度方面還是略微差一些。所以我們轉向了springcloud。在後者的基礎上,我們做了6個模組的公升級改造,因為spring的思路是把東西做到「能用」,而我們追求的是「好用」,這也是偏向技術的開發者和偏向於業務的開發者,思維習慣的差別,對於業務而言,不斷優化是應有之義。。

infoq:以黑少的經驗來看,團隊應該如何分配人力等各方面的資源,以提公升開發的效率?

於人:還是回到康威定律,資源配置取決於公司業務的發力方向,兼顧考慮人員規模導致的協同性問題。微服務有個妙處,它將乙個複雜的業務分解成乙個個簡單業務,那麼乙個個簡單的業務就可以按需匹配,在乙個最高效的人數上去完成這件事、聚焦這件事。根據亞馬遜貝佐斯「兩個披薩」的管理思想,5 ~ 10個人的團隊規模效率最高。微服務有高內聚的特點,由5-10個人完成這個服務,與其他團隊之間的溝通就不需要那麼多,尤其我們平台又解決了團隊間溝通協調的問題,可以進行服務組裝。每乙個小團隊就聚焦將自己的模組搞到極致、搞到完美,大家就能「我為人人、人人為我」。

infoq:目前,微服務開發經常會面臨依賴滯後的問題,開發者應該遵循哪些原則,可以提公升開發交付的效率?

於人:其實整個微服務,我們在落地微服務的思想是說約定大於配置,在最開始之前,大家應該遵照的是一套相對更現實的解決方案,我們現在選的是springcloud的一套整體的底層框架標準和邏輯,在這個底層協議與基礎上做了一些讓開發人員用起來更簡單、更易用、更人性化的功能,但是底層還是遵循springcloud的這一套整體的標準。

infoq:您是否在微服務配置方面有一些經驗可以分享?在docker上部署springcloud的微服務,如何才能實現配置的自動化更新?

於人:這個理論上講,實現自動化更新並不難,外面也有一些開源的配置中心都實現了,本身spring是支援介面呼叫的。難在哪兒?這就不得不說,為什麼隨行付推出的configkeeper配置中心被大家歡迎,難點就在於什麼時候去觸發這個配置中心,如果你部署上去立刻觸發,有可能造成災難性的結果:一旦這個配置配錯了,整個服務就停了。這就是我說的「能用」和「好用」的區別,我們為了做到「好用」,做了多重防範措施,首先在配置修改上具有版本之間的比對,改了哪兒一目了然,改了一行就顯示一行高亮。

第二,在更新的時候,我們支援手動觸發個別的先更新,相當於灰度測試,你更新完了之後看看效果怎麼樣。

第三,當這個更新發生問題了要快速回軌,這些都是日常工作中會遇到的一些可能出現的問題。我們為了讓它「好用」,確實做了大量的工作。

infoq:黑少在未來的長期計畫有哪些?

於人:聚焦於商店,商店的本質功能是基於互換的資訊透明化,具體而言就是匹配需求與供給。為了讓盡可能多的模組流通起來、進行共享,我們必須聚焦於微服務的萬物互聯,無論用誰家的雲平台、無論用什麼語言開發、無論用什麼微服務協議來通訊,最後都能在黑少這個平台上完成它們之間的互相呼叫,這樣就能真正實現大共享,實現軟體開發行業去重這個理想。

實現這個理想也許需要時間,但是推進這個理想過程,就能為開發者節省大量精力用於技術創新,或者去做自己想做的事情。降低開發成本之後,也會有更多企業、創業者能夠受惠於科技,讓科技服務下沉到更小、更輕的企業層面——這樣才能做大to b蛋糕,如果只是零和競爭, 那麼to b革命就無從談起。

基於微服務,打造共享開發平台

於人,隨行付 cto u0026amp 研發中心總經理,黑少 微服務商店創始人,tgo 鯤鵬會成員,中國人民大學emba,全棧工程師,擁有14年開發經驗,11年技術管理經驗。於人 首先是社會發展趨勢,眼下我們整處於不確定性時代,外界環境變化非常快,因此企業需要在系統上快速響應這些變化。微服務最大的特...

移動開發即服務,騰訊雲移動開發平台打造開發新模式

3.異常崩潰檢測 bugly 為移動開發者提供專業的異常上報和運營統計,幫助開發者快速發現並解決異常,同時掌握產品運營動態,及時跟進使用者反饋。mobileline的最終目的是為移動開發者提供完善的企業級移動開發解決方案,涵蓋從研發構建到上線運營的整個生命週期,後面將會陸續開放實時資料庫 a b t...

微服務開發規範

版本號的格式為 a.b.c 又稱 major.minor.patch 遞增的規則為 a 表示主版本號,當 api 的相容性變化時,a 需遞增。b 表示次版本號,當增加功能時 不影響 api 的相容性 b 需遞增。c 表示修訂號,當做 bug 修復時 不影響 api 的相容性 c 需遞增。詳細的規則如...