於人，隨行付 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 需遞增。詳細的規則如...