色逼成人综合一二三区,操久在线,东京热AV中文字幕,狠狠干五月天,日本内射网站在线观看,男人射美女,日韩欧美一区二区三区 ,国产中文99,91小仙女jK白丝袜呻吟

作者：阿里云數(shù)據(jù)庫OLAP產(chǎn)品部——韓述

工作十年，一直專注于技術(shù)研發(fā)。一路走來，既參與過從第一行代碼寫起的純自研的項(xiàng)目，也做過基于開源產(chǎn)品擴(kuò)展慢慢轉(zhuǎn)型成自研的項(xiàng)目，還負(fù)責(zé)過開源社區(qū)的管理和維護(hù)。

輾轉(zhuǎn)折騰的過程中，有幸以各種不同角色（小白用戶、開發(fā)者、維護(hù)者、管理員）參與過數(shù)個(gè)頂級(jí)開源項(xiàng)目Nginx、K8s、Postgres等的開發(fā)和維護(hù)。尤其是近幾年一直在做開源結(jié)合自研類型的基礎(chǔ)平臺(tái)類項(xiàng)目，走過一些彎路，踩過很多坑，也總結(jié)了一些經(jīng)驗(yàn)，本文將重點(diǎn)分享開源結(jié)合自研項(xiàng)目的一些經(jīng)驗(yàn)。

開源 VS 自研

開源好還是自研好一直以來都是一個(gè)很有爭議的話題，幾乎是任何一個(gè)產(chǎn)品，尤其是基礎(chǔ)平臺(tái)類產(chǎn)品繞不開的一個(gè)抉擇。

開源優(yōu)勢：入門門檻低，有很多可以復(fù)用的成果。通常而言，功能比較豐富，周邊生態(tài)也比較完善，投入產(chǎn)出比比較高。一句話總結(jié)，投入少，見效快。

開源劣勢：內(nèi)核不容易掌控，門檻較高，通常開源的功能和實(shí)際業(yè)務(wù)有一些GAP，很多開源產(chǎn)品開箱即用做的不夠好，需要大量調(diào)優(yōu)。一句話總結(jié)，入門容易掌控難。

自研優(yōu)勢：產(chǎn)品核心技術(shù)掌控程度高，可以更好的貼著業(yè)務(wù)需求做，可以定制的更好，基于上述兩點(diǎn)，通常更容易做到良好的性能表現(xiàn)。一句話總結(jié)，量身定制。

自研劣勢：投入產(chǎn)出比略低，且對(duì)團(tuán)隊(duì)成員的能力曲線要求較高。此外封閉的生態(tài)會(huì)導(dǎo)致周邊支持缺乏，當(dāng)需要一些新需求時(shí)，往往都需要定制開發(fā)。一句話總結(jié)，啥事都要靠自己。

開源結(jié)合自研

事實(shí)上，自研的理論上限更高，但同時(shí)意味著更高的入門門檻以及前期投入，而開源的上限容易受限于開源項(xiàng)目本身的設(shè)計(jì)、架構(gòu)、生態(tài)等限制，但是初始創(chuàng)業(yè)階段更容易快速落地。有點(diǎn)類似于開發(fā)語言的選擇：C/C++更容易寫出高性能的產(chǎn)品，但同時(shí)會(huì)遇到更多功能性問題，而Java則更容易先達(dá)到業(yè)務(wù)目標(biāo)但是在后期很容易遭遇瓶頸。

如果不計(jì)成本，那么自研無疑是最好的選擇。但是大多數(shù)時(shí)候不差錢總歸只是一個(gè)美好的夢想，而單純基于開源又往往無法滿足需求。于是，現(xiàn)在大部分需要巨大投入的基礎(chǔ)平臺(tái)類產(chǎn)品如中間件、數(shù)據(jù)庫、操作系統(tǒng)等，都會(huì)選擇一種折中的開源結(jié)合自研的發(fā)展方式。

這種方式早期基于或者結(jié)合開源產(chǎn)品及其生態(tài)，快速支撐業(yè)務(wù)，并從中逐步培養(yǎng)起研發(fā)團(tuán)隊(duì)，最終成長為高度掌控的自研產(chǎn)品。甚至于有些產(chǎn)品在自研一段時(shí)間之后，獲了一定的領(lǐng)先性和差異化優(yōu)勢，再次獨(dú)立開源之后在業(yè)界影響力甚大。比如典型的Google的BoringSSL就誕生自開源OpenSSL，阿里的Tengine誕生自開源Nginx，這些產(chǎn)品在自研一段時(shí)間之后獨(dú)立開源，由于其獨(dú)到的領(lǐng)先性和差異化，同時(shí)又能很好兼容已有生態(tài)，都成功占據(jù)了相當(dāng)?shù)氖袌龇蓊~。

選擇開源結(jié)合自研的路線，一般都是出于成本和效益的權(quán)衡。但是為什么能夠獲得比較好的成本和收益之間的平衡呢？下面從三個(gè)方面來詳細(xì)分析一下：

1、論開源社區(qū)的三大財(cái)富

要想長成為一棵茂密的參天大樹，必然需要發(fā)達(dá)和龐大的根系支持，而往往開源社區(qū)恰好已經(jīng)具備了這一點(diǎn)。如何讓自己的產(chǎn)品長在開源社區(qū)的強(qiáng)大的根系上，并與之緊密結(jié)合，從中吸取營養(yǎng)，再通過光合作用長出新枝，是開源與自研結(jié)合的核心魅力所在。

一般來說開源社區(qū)至少有三大寶貴財(cái)富值得我們繼承

優(yōu)秀而歷經(jīng)考驗(yàn)的Base Code，包括附屬的周邊生態(tài)
源源不斷更新的Feature，Bugfix以及它們背后的tester們
世界通行的人才圈子，良性的競爭和循環(huán)

如何利用好他們，并能夠在其基礎(chǔ)上創(chuàng)新、發(fā)展，是本文要重點(diǎn)分享的經(jīng)驗(yàn)。

2、論紅花和綠葉

所有做技術(shù)項(xiàng)目的人都知道，在一個(gè)項(xiàng)目或者產(chǎn)品中，內(nèi)核相關(guān)技術(shù)的占比肯定不會(huì)超過一半，即使是內(nèi)核技術(shù)中也有相當(dāng)多的是基礎(chǔ)、瑣碎卻必須的框架層、適配層、業(yè)務(wù)邏輯等，真正能有重大突破的亮點(diǎn)，少之又少。

而內(nèi)核技術(shù)之外，產(chǎn)品易用性、周邊配套工具、兼容性等等又甚至比產(chǎn)品核心技術(shù)本身更能決定一款產(chǎn)品的普及程度。負(fù)責(zé)這些方向的研發(fā)人員和團(tuán)隊(duì)往往更像是紅花邊上的綠葉。一直以來這都是一個(gè)難以調(diào)和的矛盾，要么很容易導(dǎo)致人員和團(tuán)隊(duì)的頻繁流失，要么導(dǎo)致畸形發(fā)展，最終產(chǎn)品變成頭重腳輕的畸形兒，核心能力強(qiáng)大而周邊配套卻極為羸弱。

除此以外，日復(fù)一日，年復(fù)一年，海量而繁瑣的測試工作，艱辛的Bug排查和修復(fù)工作又不知道消耗了多少技術(shù)人的寶貴青春。

事實(shí)上，開源和自研結(jié)合的項(xiàng)目，其中很重要的一個(gè)點(diǎn)，就是如何讓開源去承擔(dān)綠葉的職責(zé)，從而自研的力量可以更多得集中到如何做一朵紅花。

經(jīng)驗(yàn)一：

成為紅花的秘訣是讓開源做好你的綠葉

讓自研成為開源的綠葉中長出的一朵紅花，是一門藝術(shù)。開源社區(qū)，最寶貴的財(cái)富不僅僅是代碼，更重要的是用戶。誠然社區(qū)里的世界頂級(jí)程序員們是一項(xiàng)重要資源，但是更加稀缺的是那些始終在使用開源產(chǎn)品的用戶和業(yè)務(wù)。他們?nèi)諒?fù)一日年復(fù)一年的在做著各種測試，他們?cè)诿赓M(fèi)使用開源產(chǎn)品的同時(shí)，也在默默貢獻(xiàn)著自己的力量，與開源社區(qū)相互成就著，這是某一個(gè)公司內(nèi)部私有的自研產(chǎn)品難以企及的巨大投入。

翻一翻Github上那一個(gè)個(gè)Bugfix和一個(gè)個(gè)Issue，任何一個(gè)都有可能是造成一次重大故障的元兇，你的心里慌不慌，背后涼不涼。此外有序的社區(qū)版本的發(fā)布，新Feature的研發(fā)和探索，用戶使用反饋問題的修復(fù)，這些都將是你產(chǎn)品的最好助力。當(dāng)然開源社區(qū)也同樣需要更多的參與者（無論是開發(fā)者還是使用者），你和開源社區(qū)共同成就著對(duì)方。

做好開源結(jié)合自研項(xiàng)目的首先一條，就是要平衡好和開源的關(guān)系，盡量不要脫離開源的大框架和生態(tài)圈，保持與其的版本同步，站在巨人的肩膀上前行。同時(shí)又不能完全人云亦云的亦步亦趨，需要有自己的思考和研判，集中力量在關(guān)鍵領(lǐng)域進(jìn)行突破和創(chuàng)新，才能有所成就。

3、論組織的安全性

大部分公司開門是掙錢的，很多時(shí)候需要考慮的不僅僅是技術(shù)的先進(jìn)性，還要考慮業(yè)務(wù)的連續(xù)性，借用HR的一個(gè)術(shù)語就是組織的安全性。

顯然，自研產(chǎn)品更加需要關(guān)注這一點(diǎn)，自研產(chǎn)品的核心研發(fā)流失，更容易帶來災(zāi)難性后果。其實(shí)，明面上的流失還是其次的，真正可怕的在于，新鮮血液的融入成本。我們經(jīng)常會(huì)在XX吐槽區(qū)看到，一個(gè)新人吐槽XX公司XX部門，幾個(gè)老白兔，技術(shù)水平很差，但是手里把握著幾萬行所謂的核心代碼，作威作福，感覺自己出頭無望云云。

實(shí)際上，所謂的老白兔們，又何嘗不是被困在了這所謂的自研核心的圍城中呢。團(tuán)隊(duì)以及團(tuán)隊(duì)的Leader也沒有動(dòng)力去改善風(fēng)氣，以及吸引人才。一來外部不熟悉的人才很難上手，來了短期內(nèi)也派不上用場，二來內(nèi)部的人才和外部技術(shù)不通，內(nèi)部人才想流失也不是那么容易的，沒必要多費(fèi)心思去挽留。惡性循環(huán)，很容易就走入死胡同。

舉例來說，如K8s這樣的世界TOP級(jí)項(xiàng)目，擁有全世界通行的內(nèi)核框架、接口和使用方法，外部大量優(yōu)秀的內(nèi)行人才可待發(fā)掘，由于使用相同的技術(shù)棧，他們很容易快速融入團(tuán)隊(duì)，甚至推動(dòng)團(tuán)隊(duì)帶來質(zhì)變。

內(nèi)部的人才面對(duì)競爭，固然沒有那么舒服愜意，但是望著手中的K8s這一走遍天下都不怕的技術(shù)硬通貨，是不是給自己打工時(shí)更有干勁了呢。團(tuán)隊(duì)和團(tuán)隊(duì)Leader能不努力提升福利，營造良好氛圍么，畢竟大門敞開，來去自由。這樣很容易形成良性循環(huán)，團(tuán)隊(duì)產(chǎn)出高，公司賺到錢，大家有收獲和成長，皆大歡喜。

從Gartner技術(shù)成熟度曲線說起

說了一大堆開源結(jié)合自研的好處，是否開源結(jié)合自研的產(chǎn)品就一定能成功？當(dāng)然是否定的，任何一個(gè)產(chǎn)品都是經(jīng)歷挑戰(zhàn)，一步一步闖關(guān)才最終得以成功的。眾所周知，世界權(quán)威評(píng)測機(jī)構(gòu)Gartner有一個(gè)技術(shù)成熟度曲線，用來描述一個(gè)技術(shù)方向的生命周期，大部分的技術(shù)方向，都很難跳出萌芽期、期望膨脹期（過熱期）、低谷期（幻滅期）、復(fù)蘇期、成熟期這樣的規(guī)律。

事實(shí)上，這個(gè)曲線在哲學(xué)上確有一定道理，大部分事物都很容易走入這樣一個(gè)輪回。做一款開源結(jié)合自研的產(chǎn)品的過程，很多時(shí)候，也會(huì)是類似的情況。

萌芽期：一般伴隨著需求的產(chǎn)生，為了解決一個(gè)或一系列問題，通過選型、對(duì)比、論證等，最終引入了一款開源產(chǎn)品，開始試用。通常這時(shí)候懵懵懂懂，更多的是小心的試探。大家都是通過對(duì)問題的分析，選擇一些場景，試用該產(chǎn)品，驗(yàn)證其效果以及穩(wěn)定性等。對(duì)于開發(fā)團(tuán)隊(duì)來說，這個(gè)階段，對(duì)開源產(chǎn)品的源碼都不夠熟悉，只能做一些參數(shù)調(diào)優(yōu)以及小規(guī)模的功能改造。

期望膨脹期（過熱期）：在熟悉了一段時(shí)間后，由于開源產(chǎn)品很多都具有一定的成熟度，并且能夠被最終選型使用的產(chǎn)品，往往早已在市場上經(jīng)過激烈的廝殺，至少是一款世界一流甚至世界第一級(jí)別的產(chǎn)品。所以，大多數(shù)情況下，都能很好的解決一部分或一系列問題，甚至快速發(fā)揮舉足輕重的作用，讓大家嘗到甜頭。

這時(shí)，通常會(huì)快速的進(jìn)行擴(kuò)張。擴(kuò)張是兩方面的，一方面是對(duì)產(chǎn)品的改造，伴隨著大量二次開發(fā)，往往會(huì)對(duì)很多模塊進(jìn)行重構(gòu)、擴(kuò)展，以更好的適配公司的業(yè)務(wù)需求。另一方面是業(yè)務(wù)的大量落地，經(jīng)過了早期的萌芽階段，產(chǎn)品的作用和穩(wěn)定性得到驗(yàn)證，大規(guī)模推廣期往往都在這時(shí)完成。同在在這個(gè)階段中，產(chǎn)品團(tuán)隊(duì)的規(guī)模會(huì)得的很好的擴(kuò)張，取得不錯(cuò)的業(yè)績。

幻滅期（低谷期）：經(jīng)過了一段時(shí)間的大規(guī)模二次開發(fā)，以及大規(guī)模的業(yè)務(wù)推廣。產(chǎn)品會(huì)遇到一個(gè)嚴(yán)重的瓶頸期。通常也會(huì)表現(xiàn)在兩個(gè)方面。對(duì)于開發(fā)側(cè)來說，經(jīng)過1-3年的過熱期，很多產(chǎn)品的源碼已經(jīng)被改的面目全非，然而這段時(shí)間開源社區(qū)也在有序的演進(jìn)著，此時(shí)將出現(xiàn)一個(gè)我們通常所說的版本分叉問題。進(jìn)而導(dǎo)致開源社區(qū)新的優(yōu)異特性，難以被集成，而大量自研的特性又給產(chǎn)品背上承重的維護(hù)負(fù)擔(dān)，此時(shí)如果再有研發(fā)人員的變動(dòng)，簡直是雪上加霜。

社區(qū)的代碼越來越難合并了，而自研的代碼又有大量的問題需要自行投入力量修復(fù)，甚至原本開源部分的代碼的新Bugfix都已經(jīng)無法直接復(fù)用了。大多數(shù)的團(tuán)隊(duì)都會(huì)在此時(shí)不得不放棄對(duì)開源版本的支持。然而開源版本同樣在飛速奔跑著，不出一兩年，大家就會(huì)覺得，自研產(chǎn)品越來越臃腫和落后，已經(jīng)追不上開源的進(jìn)度了。

另外從業(yè)務(wù)側(cè)來看，海量的業(yè)務(wù)涌入，固然帶來了不錯(cuò)的業(yè)績表現(xiàn)，但是也帶來了大量的線上故障，很多隱藏的問題逐漸暴露出來，運(yùn)氣不好的時(shí)候，連續(xù)發(fā)生重大故障才是真讓人崩潰。

此外增長越來越困難了，當(dāng)?shù)痛沟墓麑?shí)都被摘得差不多的時(shí)候，大家會(huì)發(fā)現(xiàn)，整個(gè)研發(fā)團(tuán)隊(duì)，已經(jīng)慢慢變成了運(yùn)維團(tuán)隊(duì)。有很多（超過一半）的產(chǎn)品，此時(shí)就放棄了。通常而言，一是找一個(gè)新的產(chǎn)品，重頭再來，或者就干脆留上一兩個(gè)人維護(hù)，大部分轉(zhuǎn)戰(zhàn)其他領(lǐng)域去了。

復(fù)蘇期：能熬過幻滅期的產(chǎn)品，很多時(shí)候，倒不是研發(fā)團(tuán)隊(duì)自身做的有多好，更多的是產(chǎn)品本身的競爭力，以及不可替代性。很多時(shí)候也看領(lǐng)域發(fā)展的，有時(shí)候剛好有基礎(chǔ)理論的更新：比如席卷全世界的云原生浪潮；比如Linux2.6的異步事件機(jī)制；比如大數(shù)據(jù)領(lǐng)域批處理、流處理的基礎(chǔ)理論發(fā)生演進(jìn)，這樣剛好有機(jī)（借）會(huì)（口）可以用下一代的產(chǎn)品，來填上這個(gè)坑。

但是如果不幸，新一代的產(chǎn)品換湯不換藥，沒有本質(zhì)上變化，就會(huì)出現(xiàn)，老產(chǎn)品維護(hù)不下去了，而新產(chǎn)品又推不動(dòng)，沒人買單的尷尬情況。復(fù)蘇期，是一個(gè)艱苦難熬的階段，總結(jié)來說，就是不斷的填坑，放棄一些性價(jià)比低的自研模塊和特性，重構(gòu)部分持續(xù)有價(jià)值和生命力的模塊，并重新和開源融合的過程。

成熟期：從研發(fā)角度看，能進(jìn)入這個(gè)階段的產(chǎn)品逐漸在開源和自研之間找到了較好的平衡。構(gòu)建了與開源社區(qū)共存和相互促進(jìn)的架構(gòu)和形態(tài)，大規(guī)模業(yè)務(wù)落地的瓶頸問題得到解決，一般這個(gè)階段屬于收獲期，研發(fā)的投入可以逐漸減少，但是產(chǎn)出卻能夠很好的維持，最關(guān)鍵的是產(chǎn)品形成了良好的架構(gòu)，不那么依賴于某一個(gè)人的熟悉程度，新人能夠快速的融入，產(chǎn)品進(jìn)入可持續(xù)發(fā)展階段。

萌芽期

產(chǎn)品的早期，通常有3個(gè)核心問題，需要解決：

定義問題：確定公司的業(yè)務(wù)目前已經(jīng)或者未來即將遇到的問題，只有明確了問題，才有解決的必要，也就有了目標(biāo)，這是所有后續(xù)一切行動(dòng)的基礎(chǔ)。
開源選型：通過一系列方法，包括并不限于查閱資料、試用、閱讀源碼、找人打聽等等各種手段對(duì)比選擇一款最match之前定義的問題，并且符合公司和業(yè)務(wù)未來發(fā)展情況的Base產(chǎn)品。
源碼掌控：很多時(shí)候，上面兩條都由項(xiàng)目的Leader代勞了，開發(fā)同學(xué)遇到的最大挑戰(zhàn)往往是，開源代碼動(dòng)輒幾十萬幾百萬行，如何熟悉和上手掌握是一個(gè)很大的挑戰(zhàn)。借用一句傳說中的俗語，改不改得動(dòng)。

定義問題

問題的定義，是聯(lián)結(jié)業(yè)務(wù)和技術(shù)的重要一環(huán)，往往是所有技術(shù)相關(guān)工作中，最重要，但卻又是最容易被忽略的。通常而言，有兩個(gè)需要注意的，一是要盡量看一類問題，去解決共性需求，并且要從領(lǐng)域的角度系統(tǒng)的去看，要盡量避免去看個(gè)例問題，去解決個(gè)性需求。另一個(gè)就是要以發(fā)展的眼光來看待問題，信息爆炸時(shí)代，業(yè)務(wù)的增長總是很快的，可能從幾千人訪問到幾千萬人訪問只需要幾年時(shí)間，研發(fā)必須要提前布局。

開源選型

千里之行始于足下，然而這第一步邁向的方向?qū)?huì)給今后數(shù)年，甚至十?dāng)?shù)年的發(fā)展帶來深遠(yuǎn)影響。尤其是一些關(guān)鍵核心項(xiàng)目的技術(shù)選型，幾乎一旦定型，后期很難有重大變化，因?yàn)槌杀緦?shí)在太高（人力還是其次，風(fēng)險(xiǎn)才是最大的成本）。

眾所周知，選型主要從幾個(gè)方面去進(jìn)行，比如影響力、先進(jìn)性、活躍度等等，不需要過多贅述。這里重點(diǎn)說些容易被忽視的問題：

與一般通用的僅僅使用開源項(xiàng)目不同，更多需要考慮的是后續(xù)的二次開發(fā)，以及持續(xù)的維護(hù)擴(kuò)展。我們不僅僅是選擇一個(gè)開源項(xiàng)目，更重要的是要選擇一個(gè)優(yōu)秀的框架，我們需要基于這個(gè)框架向前演進(jìn)，所以源碼的質(zhì)量，架構(gòu)的先進(jìn)性就會(huì)很大程度上影響我們的傾向。
舉一個(gè)具體例子，對(duì)于Web服務(wù)器的選型，Nginx VS Apache。從流行度上看，Apache的使用規(guī)模和生態(tài)是遠(yuǎn)大于Nginx的，但是Nginx是基于Linux2.6以上內(nèi)核的異步多路復(fù)用架構(gòu)設(shè)計(jì)的，而Apache是多進(jìn)程模型。簡單來說，Nginx可以輕松應(yīng)對(duì)百萬連接，而Apache則顯得老邁了（訪問量一大就容易遇到瓶頸）。所以全世界TOP級(jí)別的公司幾乎清一色是Nginx系。
一定要先定義問題，再做選型。只有問題定義清楚了，才能去想對(duì)應(yīng)解決問題的方案，整個(gè)動(dòng)作才能不變形。我遇到過的重大失敗的項(xiàng)目，很多都是，先選定了一個(gè)開源產(chǎn)品，然后才來丈量業(yè)務(wù)，對(duì)著已經(jīng)選定的產(chǎn)品挖掘問題。
這無異于碰運(yùn)氣，運(yùn)氣好，找到一些場景去解決了。運(yùn)氣不好，你選擇的開源產(chǎn)品或者技術(shù)路線根本不適合公司或者業(yè)務(wù)的情況，你就死掉了。就好比醫(yī)生看病，肯定是首先看癥狀確定你哪里有問題，然后選擇合適的藥去醫(yī)治，而不可能先預(yù)設(shè)好要用的藥，再來找有沒有對(duì)應(yīng)的病。

源碼掌控

通常來說，問題定義和開源選型在幾周至多幾月，肯定結(jié)束了，真正漫長卓絕，需要奮斗的第一場硬仗，往往都是對(duì)開源項(xiàng)目的源碼掌控關(guān)。根據(jù)項(xiàng)目的復(fù)雜度和規(guī)模，需要半年到數(shù)年不等的一個(gè)周期。

經(jīng)驗(yàn)二：

熟練使用Perf，幫助你跨過第一個(gè)門檻

無論任何項(xiàng)目或者產(chǎn)品，都無法脫離操作系統(tǒng)，CPU、內(nèi)存、IO、網(wǎng)絡(luò)幾大件，最終都需要依賴內(nèi)核提供的接口。熟練使用Perf，可以幫助你在對(duì)產(chǎn)品完全不熟悉，無從下手的情況下，跨過第一個(gè)門檻。阿里內(nèi)部有一個(gè)叫做扁鵲的產(chǎn)品，可以在進(jìn)行Perf時(shí)，繪制出調(diào)用關(guān)系，非常好用。如果不使用阿里內(nèi)部的工具也可以，如下的圖，是我使用開源的工具 perf + gprof2dot + graphviz 畫出的調(diào)用關(guān)系圖

在Centos或Ubuntu上只需要如下簡單幾步，就能看到圖了

使用Perf出來的運(yùn)行時(shí)調(diào)用關(guān)系，去熟悉一個(gè)產(chǎn)品，可以更加有的放矢的理清主鏈路（占比高的自然是核心鏈路），并且可以自頂向下的梳理整個(gè)產(chǎn)品的架構(gòu)，避免一上手就看靜態(tài)代碼的茫然和混亂，當(dāng)有一定認(rèn)識(shí)之后再與靜態(tài)類圖結(jié)合起來看，會(huì)更加清晰。而在這個(gè)過程中，說不定還會(huì)有意外的驚喜，比如發(fā)現(xiàn)一些深紅色的熱點(diǎn)函數(shù)，優(yōu)化一下，也很有成就感不是么？

對(duì)項(xiàng)目有一定熟悉之后，就要慢慢開始嘗試進(jìn)行修改了，通常是從Fix Bug開始，這個(gè)一般人都知道。有時(shí)候產(chǎn)品還沒有大規(guī)模在業(yè)務(wù)上部署，所以也遇不到Bug，這時(shí)甚至可以去開源社區(qū)翻翻Issue，找一些別人提的問題嘗試解決，并提交MR給社區(qū)，目的是獲得社區(qū)給你反饋，你改的對(duì)不對(duì)，好不好，通常社區(qū)都有更熟悉的負(fù)責(zé)人會(huì)給你反饋，如果沒有反饋，那也是一種反饋（你可能完全南轅北轍了，自己需要找找問題）。

最后需要注意的是，TOP級(jí)別的項(xiàng)目，大部分都有很多源碼解析的分享，一定要多看看別人消化過一輪的成果，切忌自己一個(gè)人埋頭到代碼里一陣瞎看，不但枯燥乏味效率低下，關(guān)鍵是沒有任何反饋，代碼都是連環(huán)的，你可能中間某一步理解方向是錯(cuò)的，但是自己也不知道，導(dǎo)致后面全部帶歪了瞎耽誤功夫。

經(jīng)驗(yàn)三：

分享是提高自己的最好方式

對(duì)標(biāo)題沒有寫錯(cuò)，分享是提高自己而不是別人的最好方式。當(dāng)你得知，你寫的分享文章，或者分享的Talk，將會(huì)被很多人從各個(gè)角度研究、提問或推敲的時(shí)候，你就不會(huì)對(duì)一些問題似是而非，懵懵懂懂，就有壓力和動(dòng)力去鉆研透徹他們。一場分享下來，聽眾們往往只是對(duì)某一個(gè)領(lǐng)域入了個(gè)門而已，分享者卻往往已經(jīng)成為了這個(gè)領(lǐng)域的專家。

這個(gè)世界上，沒有人天生就是專家，所謂專家只是他在這個(gè)方向上花的時(shí)間多，研究的透徹罷了。逼迫自己，甚至是整個(gè)研發(fā)團(tuán)隊(duì)，拆分開源項(xiàng)目，分模塊撰寫原理、源碼解析，甚至整理成書，通過網(wǎng)絡(luò)、媒體等各種載體公開宣傳，一方面可以提升影響力，建立用戶心智，擴(kuò)大招聘范圍。更重要的是參與的人，會(huì)從中自（被）然（逼）的獲得提升。

定期的組織內(nèi)部分享，通常是研發(fā)團(tuán)隊(duì)都會(huì)采用的方式。但是嘗試體系化的編撰一份功能大全或者源碼解析指南，也許會(huì)讓你獲得更多的沉淀和提高。甚至于可以更好的保留和傳承，即使團(tuán)隊(duì)發(fā)生變化，后面的新同學(xué)，或者接手的團(tuán)隊(duì)，都能夠很好的繼承前人的成果。

期望膨脹期（過熱期）

隨著產(chǎn)品逐漸有標(biāo)桿業(yè)務(wù)落地，后續(xù)的推廣復(fù)制往往水到渠成。業(yè)務(wù)規(guī)模會(huì)很容易的快速膨脹，可能一年兩年的時(shí)間內(nèi)，使用產(chǎn)品的業(yè)務(wù)個(gè)數(shù)能夠從個(gè)位數(shù)迅速增長到幾千甚至幾萬個(gè)。洶涌而來的業(yè)務(wù)需要維護(hù)，海量的需求讓人崩潰，好在價(jià)值的體現(xiàn)讓人動(dòng)力十足，這段時(shí)間總是讓研發(fā)同學(xué)痛并快樂著。

事實(shí)上，除了一開始的選型定基調(diào)比較重要之外，一個(gè)產(chǎn)品最關(guān)鍵的時(shí)期，就是這個(gè)時(shí)候。能否更平滑、更快速的度過后面的幻滅期，包括進(jìn)入成熟期之后能走多遠(yuǎn)，相當(dāng)大程度取決于能否處理好這個(gè)階段。

身處過熱期，其實(shí)面對(duì)的直接困難和挑戰(zhàn)并不多，因?yàn)閳F(tuán)隊(duì)的規(guī)模很容易獲得大幅擴(kuò)張，業(yè)務(wù)需求也源源不斷，一切欣欣向榮，所以在這個(gè)階段，最重要是要為未來考慮，多想想兩三年之后的幻滅期。

前面說過，幻滅期最大的兩個(gè)問題：一是大量的業(yè)務(wù)將放大穩(wěn)定性風(fēng)險(xiǎn)的概率，很小的一個(gè)問題都容易帶來災(zāi)難性后果，整個(gè)項(xiàng)目會(huì)背上越來越重的包袱，跑的越來越慢，甚至跑不動(dòng)了。另一個(gè)是和開源社區(qū)的分叉問題，一旦和開源分叉，就無法享受到開源紅利，這個(gè)產(chǎn)品就和自研無異了，需要巨大的投入去照顧方方面面。針對(duì)于此，有這樣一些經(jīng)驗(yàn)：

經(jīng)驗(yàn)四：

找到那個(gè)撬起地球的支點(diǎn)才是最牛的

通常情況下，實(shí)現(xiàn)一個(gè)同樣的二次開發(fā)需求，會(huì)有兩種方式，一種完全魔改掉開源的實(shí)現(xiàn)，甚至于把某一個(gè)模塊徹底重寫。另一種是完全讀懂原作者的精髓，通過在最契合的部位，做一些微調(diào)，或者通過插件機(jī)制輔助加上少量的的內(nèi)核改動(dòng)支持的方式完成。

曾經(jīng)，宣傳自身研發(fā)實(shí)力的標(biāo)志就是完全重構(gòu)XXX開源，整個(gè)XXX層都被重寫了，大幅提高XXX，云云。然而時(shí)間一長，大家就會(huì)慢慢發(fā)現(xiàn)。新寫的模塊和開源無法兼容，開源生態(tài)的很多插件由于內(nèi)核的機(jī)制被重構(gòu)過，不work了，很多功能沒有被完全兼容。重寫的代碼，沒有龐大的社區(qū)用戶測試和Bugfix，一旦遇到之前沒遇過的場景就問題百出，需要像看護(hù)一個(gè)寶寶一樣，小心試探著使用。

踩過那些坑之后，今天我們?cè)絹碓角逦囊庾R(shí)到，在做開源項(xiàng)目的時(shí)候，大改特改其實(shí)并不難，真正難的是如何找到那個(gè)撬動(dòng)地球的支點(diǎn)，高（深）手（得）出（精）手（髓），可能只需要在正確的位置改上10行代碼，或者增加些邏輯就能獲得巨大的提升，真正的關(guān)鍵，反而是找到那個(gè)位置。

當(dāng)然，也不能說我們就不要或者盡量少的修改開源代碼。相反要大膽的改，尤其是關(guān)鍵核心鏈路，能改，并且改了不出問題，還達(dá)到預(yù)期的目標(biāo)，這是研發(fā)能力成熟的標(biāo)志。關(guān)鍵在于，不要為了重構(gòu)而重構(gòu)，需要把目標(biāo)的核心放在客戶價(jià)值上。

舉個(gè)簡單的例子，開源有一個(gè)機(jī)器列表管理模塊，可能節(jié)點(diǎn)數(shù)少的時(shí)候沒問題，節(jié)點(diǎn)一多，運(yùn)行就比較慢成為瓶頸，一種解法是整個(gè)模塊重構(gòu)，引入XX算法，重寫幾W行代碼，完全自研XX技術(shù)，如何XX牛逼，達(dá)到XX效果。結(jié)果卻是，很難和原先的模塊完全兼容，有些功能丟失了，甚至查看機(jī)器列表的周邊工具都不Work了。

另一種解法，深入到源碼的原理中，其實(shí)核心的瓶頸很簡單，開源用的鏈表保存，不支持隨機(jī)尋址，找一臺(tái)機(jī)器就要遍歷，解決方法就是增加一種數(shù)組類型的保存方式，支持快速在大量機(jī)器中尋址。顯然后一種方法代碼切口很小，只是對(duì)數(shù)據(jù)結(jié)構(gòu)使用的地方做些if else替換即可，原先所有能力都兼容對(duì)齊，效果可能也達(dá)到了重寫整個(gè)模塊95%以上。

后續(xù)在幻滅期、復(fù)蘇期等等的可維護(hù)性，可持續(xù)發(fā)展性方面遠(yuǎn)遠(yuǎn)優(yōu)異。當(dāng)然這只是一個(gè)小例子，實(shí)際中更多的是遇到更復(fù)雜的Trade off。但是保持一顆堅(jiān)信少即是多的心，是必要的。

經(jīng)驗(yàn)五：

盡量保持和開源在面子上的一致性

既然是結(jié)合自研，在關(guān)鍵核心領(lǐng)域一定要有核心突破，同時(shí)對(duì)于確有需求的要敢于出手，對(duì)開源進(jìn)行改造。但是突破不意味著需要把代碼改的面目全非，保持在文件結(jié)構(gòu)、風(fēng)格、函數(shù)命名等面子上的一致性是必要的：

非必要的情況下盡量保持開源架構(gòu)的目錄和文件結(jié)構(gòu)
盡量避免重命名文件、函數(shù)、變量，而是以新增的方式代替
大規(guī)模的修改是可以的，但是盡量以增加的方式，比如增加文件、函數(shù)、邏輯，而不是把原來大段的文件、函數(shù)、邏輯刪除掉
大部分的開源都是設(shè)計(jì)了擴(kuò)展能力的，結(jié)合擴(kuò)展能力輔以內(nèi)核中增加少量代碼配合。而不是簡單暴力的大段重構(gòu)
對(duì)代碼的小修改盡量保留原有的邏輯，而不是刪掉重寫

如果是C/C++，推薦用預(yù)編譯宏的方式修改代碼

這里命名方式都是有講究的，公司名 + 模塊 + 自研的特性，這種格式很容易在紛繁的代碼中區(qū)分出，這一段修改是為了XXX特性而做的適配，極大的方便后續(xù)合并開源高版本時(shí)的工作。同時(shí)在后續(xù)的維護(hù)中可以方便、安全的裁剪掉某個(gè)特性。

當(dāng)一個(gè)產(chǎn)品在數(shù)以萬計(jì)的業(yè)務(wù)被采用時(shí)，每一行代碼的修改都會(huì)變的極為謹(jǐn)慎，早期能夠更多的留下信息就會(huì)顯得極為寶貴。如果是Java或Go，那么只能使用注釋的方式，但是還是推薦不要?jiǎng)h除掉原有的開源代碼，以注釋形式保留。這樣不但有利于之后維護(hù)，更重要的是，方便單獨(dú)抽離出來，合入高版本開源Base Code中。

你問為什么？好吧，我是不會(huì)告訴你，我曾經(jīng)遇到過多少次合并高版本代碼時(shí)，一群人圍著一段被修改過的代碼討論一小時(shí)，不知道這個(gè)長的和開源不一樣的地方，究竟是應(yīng)該保留開源高版本的修改，還是保留被前人改過的邏輯。什么你說git blame？你確定blame出來的那個(gè)提交者，你還認(rèn)識(shí)？

事實(shí)上，過熱期是一個(gè)產(chǎn)品發(fā)展最快的階段，很多重大的突破（功能質(zhì)變或者性能有數(shù)量級(jí)提升）都會(huì)發(fā)生在這個(gè)階段，如果有幸經(jīng)歷這個(gè)階段，好好享受它吧，不過盡量記住上面兩點(diǎn)。

幻滅期（低谷期）

上帝欲使之滅亡,必先使其瘋狂。快速增長的業(yè)務(wù)，大量自研的新特性。伴隨而來的不只有成功的喜悅，更多的是接踵而來的故障，經(jīng)常讓人感覺新坑老坑無數(shù)危機(jī)四伏，越來越沉重的包袱，很快就會(huì)壓垮團(tuán)隊(duì)，很多時(shí)候這個(gè)艱難的時(shí)期會(huì)伴隨著人員的流失，導(dǎo)致雪上加霜。

運(yùn)氣最糟糕的時(shí)候，再遇到一個(gè)開源的隱藏坑被自研代碼觸發(fā)，然后重大故障之后，你會(huì)懷疑人生，甚至于覺得是不是路線是錯(cuò)誤的，應(yīng)該推倒重來，全部自己寫，或者干脆只有純凈的開源版，一點(diǎn)都不要再做修改了。

想要熬過幻滅期，除了在前面的過熱期，要保持克制，并打下良好的基礎(chǔ)，最關(guān)鍵的是要適當(dāng)做減法。比如合并同列項(xiàng)，砍掉低效的自研模塊，拉齊開源版本等等。

經(jīng)驗(yàn)六：

必要的時(shí)候開始做減法

隨著產(chǎn)品的發(fā)展，自研的代碼量和模塊數(shù)，會(huì)快速膨脹，尤其是在過熱期。顯然，團(tuán)隊(duì)會(huì)因此背上越來越沉重的負(fù)擔(dān)。解決方案也很簡單 —— 減少自研代碼量。途徑有三個(gè)：

放棄自研而采用高版本的開源對(duì)應(yīng)的實(shí)現(xiàn)。對(duì)于曾經(jīng)開源沒有的能力或者優(yōu)化點(diǎn)，當(dāng)時(shí)是通過自研實(shí)現(xiàn)的，而可能過了1，2年，開源也有了，這種情況就可以做合并同列項(xiàng)。相應(yīng)的自研模塊可以完成歷史使命光榮退役，改用開源在高版本中的類似能力替代。
把自研的模塊和優(yōu)化回饋開源社區(qū)。有些自研團(tuán)隊(duì)，會(huì)對(duì)自己研發(fā)的代碼嚴(yán)格保密，作為構(gòu)筑競爭力的保證，這樣做其實(shí)不是最佳的，適當(dāng)?shù)膶⒁呀?jīng)成熟的代碼回饋給開源社區(qū)既是有利于全世界的用戶們，也是對(duì)自己最好的解脫，實(shí)實(shí)在在是一個(gè)雙贏的局面。可以放下包袱投入下一階段的攻堅(jiān)。真正的壁壘，不是造一個(gè)火箭保密藏起來，而是始終有引領(lǐng)下一代潮流的能力，永遠(yuǎn)超越過去的自己更快、更好、更先進(jìn)。
砍掉一些價(jià)值不大，卻又嚴(yán)重破壞和開源一致性的模塊和優(yōu)化。在過熱期，很容易上很多KPI產(chǎn)物的項(xiàng)目，遺留很多低價(jià)值能力，實(shí)際效果微小，遠(yuǎn)不值得為之維護(hù)一份特殊的邏輯，一定要堅(jiān)定的砍掉，輕裝上陣。

最終，在幻滅期要想重生，在做了以上三個(gè)動(dòng)作之后，還剩下的自研代碼，必然是。高價(jià)值（有質(zhì)變），高適用（特別適合所在公司業(yè)務(wù)場景），有核心競爭力的，值得長期維護(hù)，并繼續(xù)演進(jìn)。

通常來說，團(tuán)隊(duì)需要一個(gè)契機(jī)，完成這個(gè)工作，開源社區(qū)大版本迭代是一個(gè)不錯(cuò)的機(jī)會(huì)，基于高版本的開源Base Code，將自研的代碼，有序合入，在這個(gè)過程中，完成上面三點(diǎn)工作。

經(jīng)驗(yàn)七：

穩(wěn)定性是一個(gè)系統(tǒng)的工程

在幻滅期最容易遇到的另一個(gè)問題是故障頻發(fā)，一來是過熱期上了大量自研的改造往往埋了很多坑，二來業(yè)務(wù)規(guī)模快速膨脹，業(yè)務(wù)多了，自然難免有疏漏，加上版本可能越來越多，管理越來越困難。有些產(chǎn)品可能就死在了一個(gè)又一個(gè)的故障中，或者干脆畏首畏尾，不敢做新的研發(fā)和發(fā)布了。

然而穩(wěn)定性是一個(gè)系統(tǒng)的工程，并不是說你不做研發(fā)和發(fā)布就能避免的，也不是說簡單的提高代碼質(zhì)量，少寫B(tài)UG就可以做到的。簡單來說至少包括幾方面：

系統(tǒng)架構(gòu)：單租戶還是多租戶的模式很大程度上會(huì)影響出問題時(shí)候的爆炸半徑，即使是多租戶模式，有沒有地域、可用區(qū)之類的容災(zāi)、隔離、甚至逃逸能力也同樣重要。架構(gòu)的設(shè)計(jì)決定了你后續(xù)能灰度的粒度，爆炸半徑，故障恢復(fù)的耗時(shí)等等。

灰度發(fā)布機(jī)制：倒不是要什么特別流程，關(guān)鍵是如何灰度，以及灰度的節(jié)奏。比如你一個(gè)核心交易業(yè)務(wù)，極其敏感，稍有抖動(dòng)就會(huì)被發(fā)現(xiàn)，那你分10批，每批間隔1小時(shí)，是足夠的（因?yàn)橛袉栴}很容易就會(huì)暴露）。而有些依賴用戶反饋的底層系統(tǒng)，你分10批，每批間隔一周，都不過分。需要根據(jù)你產(chǎn)品的特性和變更的影響靈活判斷。

監(jiān)控診斷：有些核心敏感業(yè)務(wù)，需要做到嚴(yán)格的發(fā)布監(jiān)控，除了常規(guī)的QPS，RT之類。關(guān)鍵業(yè)務(wù)要達(dá)到一個(gè)什么程度呢，比如某個(gè)版本上線了，線上的error log數(shù)量有變化，或者出現(xiàn)一些以前沒有內(nèi)容，或者比如原來10%是啥，20%是啥，剩下是啥，新版本導(dǎo)致比例發(fā)生變化了，都要去仔細(xì)研究，找到背后的原因。因?yàn)槿罩镜淖兓ǔＲ馕吨壿嫷淖兓绻穷A(yù)期外的，往往這里面就隱藏了一個(gè)潛在故障。

嚴(yán)控配置變更：我經(jīng)歷過的數(shù)個(gè)重大故障，雖然都有代碼坑在哪里，但幾乎無一不是全局配置變更最終觸發(fā)的。因?yàn)榕渲米兏?jīng)常忽略或者不具備灰度的能力。往往一個(gè)配置的變化，會(huì)突然讓線上所有系統(tǒng)走進(jìn)一個(gè)從未被測試過的代碼路徑，導(dǎo)致災(zāi)難性后果。所以對(duì)配置的變更，尤其是全局配置的人工變更，盡量要避免。取而代之的是系統(tǒng)的自動(dòng)化，常態(tài)化能力，系統(tǒng)自己根據(jù)情況按租戶選擇合適的配置，而不是人工對(duì)全局配置改來改去。

復(fù)蘇期

經(jīng)歷過幻滅期的折磨，可能還能堅(jiān)持下來的產(chǎn)品和團(tuán)隊(duì)已經(jīng)不多了，能走到這一步，恭喜你，你負(fù)責(zé)的產(chǎn)品，是一個(gè)確確實(shí)實(shí)有業(yè)務(wù)價(jià)值，有生命力的產(chǎn)品。在這個(gè)階段，雖然產(chǎn)品發(fā)展最快的時(shí)期，但是你的個(gè)人能力將得到最快的發(fā)展，因?yàn)槟憧梢哉驹谝粋€(gè)很不錯(cuò)的時(shí)間點(diǎn)，看到前人的成功經(jīng)驗(yàn)，總結(jié)和糾正他們的失誤。而你的想法還可以輕易的在海量的業(yè)務(wù)上嘗試，正確的話會(huì)有很好的收獲，錯(cuò)誤的話，也會(huì)很快得到教訓(xùn)。非常適合年輕技術(shù)人成長和學(xué)習(xí)的一個(gè)階段。

相比于過熱期瘋狂的跑馬圈地，幻滅期的重新整頓，是一個(gè)重新出發(fā)的好機(jī)會(huì)，也是一個(gè)重大創(chuàng)新最容易出現(xiàn)的時(shí)機(jī)（隨著早期的架構(gòu)完善，研發(fā)人員和團(tuán)隊(duì)的成熟，業(yè)務(wù)規(guī)模的穩(wěn)定，對(duì)技術(shù)突破的訴求和可以發(fā)揮的空間達(dá)到最高）。重點(diǎn)要做的，就是梳理清楚過去的成果，結(jié)合好開源社區(qū)的軌道，將兩者并軌發(fā)展。以最大限度的減輕包袱，有充足的精力去看下一步的創(chuàng)新點(diǎn)，集中力量去獲取新一輪的自研先進(jìn)性成果。

經(jīng)驗(yàn)八：

定期同步開源版本的升級(jí)是必要的

同步開源版本的好處是顯而易見的，最新的Bugfix可以免去你總是排查了一周，最后在社區(qū)找到一個(gè)別人都已經(jīng)修復(fù)了2年的問題，此外最新的Feature可以避免你重復(fù)造多少輪子。尤其是社區(qū)會(huì)有大量綠葉類型的增強(qiáng)，能夠給自研的工作，帶來很多互補(bǔ)的增益效果。另外最關(guān)鍵的一點(diǎn)是，你所有的研發(fā)工作，始終都是在最新的開源版本的基礎(chǔ)上進(jìn)行的，就意味著你也可以很容易的將你的成果給到開源社區(qū)，形成共贏的局面。

通常而言，有幾種跟進(jìn)開源的策略，一是實(shí)時(shí)跟進(jìn)，開源的所有變更，實(shí)時(shí)跟進(jìn)合并，二是大版本跟進(jìn)，隔上1-2年，和開源差距大了，集中進(jìn)行一波合并。這些都可以根據(jù)具體情況選擇。

我個(gè)人而言，更傾向于小版本跟進(jìn)的策略，通常開源社區(qū)都會(huì)有一個(gè)小版本發(fā)布周期，1-3個(gè)月左右會(huì)Release一個(gè)版本，一個(gè)小版本一般包含幾十至多一百個(gè)左右的Commit。合并的工作量通常不會(huì)超過一周，由團(tuán)隊(duì)成員輪流負(fù)責(zé)的話，一個(gè)10人左右的研發(fā)團(tuán)隊(duì)，一年也就輪到1-2次。并且，團(tuán)隊(duì)的成員，時(shí)常看看開源改了啥，對(duì)自己的技術(shù)和視野都是一種成長，尤其是新同學(xué)，幫助更大。

經(jīng)驗(yàn)九：

打造先進(jìn)性和創(chuàng)新性也是有技巧的

之前的經(jīng)驗(yàn)中，很多都是在分享如何和開源保持同步一致性，從而更高效的與開源協(xié)作。但是無論如何，作為一個(gè)自研項(xiàng)目，必須還是以要構(gòu)筑自身的核心競爭力和先進(jìn)性為根基的，至少也需要構(gòu)筑與開源的差異性。

在先進(jìn)性方面，開源結(jié)合自研的項(xiàng)目更有優(yōu)勢。會(huì)寫的代碼的，基本都知道面向?qū)ο蟮睦^承機(jī)制。開源項(xiàng)目，只要保持好和開源的同步性，那么很容易做到——開源有的我都有，開源沒有的我也有。開源項(xiàng)目本身大多已經(jīng)是TOP級(jí)的了，在其基礎(chǔ)上，如果能夠在某些點(diǎn)或者面上，具有獨(dú)到的創(chuàng)新或者技術(shù)先進(jìn)性，就很容易做到業(yè)界的領(lǐng)先了。雖然說，創(chuàng)新是一個(gè)很有挑戰(zhàn)且沒有固定套路的創(chuàng)造性工作，但還是有一些經(jīng)驗(yàn)可以參考的。

技術(shù)的進(jìn)步來源于業(yè)務(wù)：脫離了業(yè)務(wù)基礎(chǔ)的技術(shù)就如同空中樓閣，很難有好的發(fā)展，相應(yīng)的，業(yè)務(wù)的需求和挑戰(zhàn)往往就是創(chuàng)新的發(fā)動(dòng)機(jī)。舉幾個(gè)例子拋磚引玉：

業(yè)務(wù)規(guī)模：最典型的可能是就是K8s，別看開源的K8s如火如荼，事實(shí)上超過幾千的個(gè)節(jié)點(diǎn)的大集群，也沒怎么玩過，而今天的中國，已經(jīng)有很多企業(yè)需要管理數(shù)萬節(jié)點(diǎn)，這就需要自研的時(shí)候，針對(duì)集群規(guī)模進(jìn)行大量優(yōu)化，甚至于重構(gòu)，以支撐規(guī)模。
穩(wěn)定性：可能對(duì)于很多開源產(chǎn)品來說，99.99%的保證已經(jīng)不錯(cuò)了，但是如果恰好你的業(yè)務(wù)，或者你所在的公司至少需要99.9999%，別小看只是多了2個(gè)數(shù)字而已，很可能從架構(gòu)，到整體設(shè)計(jì)，都需要一次飛躍，才能達(dá)到。雖然實(shí)現(xiàn)困難，可是一旦成功，反而將成為一項(xiàng)先進(jìn)的核心技術(shù)優(yōu)勢，輕易難以撼動(dòng)。
性能優(yōu)化：對(duì)于很多商業(yè)產(chǎn)品來說，性能有時(shí)候可能有著遠(yuǎn)遠(yuǎn)超越成本降低的意義。比如你打開一個(gè)網(wǎng)頁，是1秒加載完成還是2秒完成加載，其意義可能遠(yuǎn)超50%成本節(jié)約，因?yàn)榭赡苋种坏娜嗽?秒之后會(huì)選擇關(guān)閉網(wǎng)頁不等加載了。流失掉這些客戶的損失是無可估量和難以彌補(bǔ)的，那么優(yōu)化這些性能，哪怕每快那么一點(diǎn)點(diǎn)，都將意義重大。這里面就很容易催生技術(shù)的革新。

與頂級(jí)商業(yè)產(chǎn)品對(duì)標(biāo)：在很多領(lǐng)域中，開源產(chǎn)品往往受到方方面面的原因制約，在部分企業(yè)級(jí)核心能力方面比較薄弱，既然做自研，那么首先可以進(jìn)攻的方向，就是這些已經(jīng)被其他商業(yè)產(chǎn)品廣泛證明有效的特性。雖然可能不是完全原創(chuàng)，但是依然可以通過依托開源的生態(tài)，做到在相應(yīng)的領(lǐng)域中，具有獨(dú)到的競爭力。舉例來說，在開源數(shù)據(jù)庫的基礎(chǔ)上，增加異地多活的災(zāi)備能力，雖然并不是獨(dú)創(chuàng)，但是在XXX生態(tài)圈中至少是領(lǐng)先的。

利用好內(nèi)核和硬件的紅利：無論任何應(yīng)用軟件，即使是基礎(chǔ)軟件，通常也是建立在硬件和Linux內(nèi)核的基礎(chǔ)之上的，近年來，隨著需求的推動(dòng)，無論從Linux內(nèi)核到CPU/內(nèi)存/網(wǎng)絡(luò)/磁盤等硬件都在革新。舉例來說機(jī)械硬盤->SSD的演進(jìn)，就誕生了多級(jí)緩存，冷熱存儲(chǔ)等等很多創(chuàng)新爆點(diǎn)。網(wǎng)絡(luò)的RDMA，DPDK等低延遲、高吞吐技術(shù)，大幅提升分布式系統(tǒng)的性能表現(xiàn)，給分布式存儲(chǔ)帶來很大機(jī)會(huì)。Linux內(nèi)核，從早期的epoll到近年來的io_uring，也在一步一步的向前發(fā)展著。通常情況，當(dāng)?shù)讓拥募夹g(shù)發(fā)生革命性變化的時(shí)候，都是上層應(yīng)用系統(tǒng)的創(chuàng)新機(jī)會(huì)。

穩(wěn)定性和健壯性也是先進(jìn)性：并不是所有的技術(shù)先進(jìn)性一定是，性能有多高，算法有多牛。很多時(shí)候，部署架構(gòu)和運(yùn)維方式的升級(jí)，帶來的穩(wěn)定性和健壯性的提升，在實(shí)際業(yè)務(wù)中價(jià)值更大。前面說過，穩(wěn)定性是一個(gè)系統(tǒng)工程，其中首要一點(diǎn)自然就是對(duì)產(chǎn)品的架構(gòu)設(shè)計(jì)的要求。通常開源產(chǎn)品只是具備一定核心功能，而如何高效，穩(wěn)定的將這些功能應(yīng)用到生產(chǎn)業(yè)務(wù)中，往往也是自研的一個(gè)核心命題。

成熟期

一路走來，能夠進(jìn)入成熟期的產(chǎn)品，十之一二，除了運(yùn)氣，堅(jiān)持也很可貴。大部分的內(nèi)核研發(fā)，在這個(gè)階段可能已經(jīng)開始轉(zhuǎn)向新的項(xiàng)目。確實(shí)，經(jīng)過了前面若干階段，產(chǎn)品已經(jīng)日漸成熟，更多的是穩(wěn)定運(yùn)行和維護(hù)即可，對(duì)于公司和業(yè)務(wù)來說，這是真正的收獲期，較少的投入即可獲得持續(xù)而穩(wěn)定的回報(bào)。不過研發(fā)工作更多的是艱苦的開荒，到了這種收獲的季節(jié)，反而比較迷茫。確實(shí)此時(shí)將目光轉(zhuǎn)向新一代的產(chǎn)品是一個(gè)正確的選擇，但同時(shí)現(xiàn)有的產(chǎn)品也不是完全沒有機(jī)會(huì)。

經(jīng)驗(yàn)十：

服務(wù)化和產(chǎn)品化也是一大競爭力

除了產(chǎn)品的核心能力的突破和創(chuàng)新外，產(chǎn)品化程度則是一個(gè)產(chǎn)品成熟度的另一個(gè)標(biāo)志。使用繁瑣、與實(shí)際業(yè)務(wù)之間不匹配的問題在業(yè)務(wù)規(guī)模有限的情況下還可以彌補(bǔ)。但是當(dāng)進(jìn)入大規(guī)模復(fù)制推廣期，矛盾就很容易凸顯。所以當(dāng)產(chǎn)品進(jìn)入成熟期，在核心技術(shù)上已經(jīng)很難有大的飛躍時(shí)，做好產(chǎn)品的易用性，可規(guī)模化復(fù)制能力也是一個(gè)很不錯(cuò)的方向。

服務(wù)化：運(yùn)維這件事情，是一個(gè)繁重枯燥卻又容不得半點(diǎn)差錯(cuò)的事情。這也是開源社區(qū)不容易觸達(dá)的領(lǐng)域。上規(guī)模的服務(wù)化運(yùn)維平臺(tái)，除了具有資源彈性的優(yōu)勢，更重要的是自動(dòng)化帶來的穩(wěn)定性，可以有效避免人工犯錯(cuò)的機(jī)會(huì)。最關(guān)鍵的是，對(duì)于客戶來說，除了看看別人的經(jīng)驗(yàn)分享無從積累踩坑的經(jīng)驗(yàn)，而規(guī)模性的服務(wù)化，有點(diǎn)類似于買保險(xiǎn)，大家抱團(tuán)踩坑（一個(gè)人觸發(fā)的問題，會(huì)在平臺(tái)的加持下，自動(dòng)幫助其他人都避免掉，而不是每個(gè)人都來踩一遍同樣的坑）。這也是現(xiàn)在大多數(shù)云廠商Paas產(chǎn)品的一大賣點(diǎn)。

合縱連橫：通常情況下，單個(gè)產(chǎn)品的能力范圍總有局限性，在實(shí)際的業(yè)務(wù)中，需要組合一系列產(chǎn)品形成解決方案。顯然，這不是開源所擅長的。有需求，而開源不具備，這就是自研的機(jī)會(huì)。聯(lián)結(jié)好上下游，形成一體化解決方案，往往是進(jìn)入成熟期的產(chǎn)品，新的增長機(jī)會(huì)。

最后分享一個(gè)小故事

我們經(jīng)常聽到一些成功的人在介紹自己的時(shí)候會(huì)很謙虛的說，自己只是站在巨人的肩膀上，才摘到了一些成果而已。