今天對圍繞SOA，雲原生，DevOps等相關產品規劃的內容做下思考總結。如果看過我前面的文章，也基本可以瞭解到當前我們整體是圍繞雲原生解決方案提供來規劃和實現相應的技術產品和元件。這裡面核心還是微服務開發框架和環境，DevOps，容器雲，API閘道器和能力開放平臺，監控運維平臺等。

傳統ESB匯流排產品和API閘道器

今天再次對整個產品規劃體系進行了重新思考，也明確了整體的產品架構和後續關鍵產品研發路線。在我部落格上面原來重心也一直圍繞ESB服務匯流排再談，雖然有不少文章也談到了API閘道器，OpenAPI能力開放平臺，微服務架構，但是都沒太詳細展開，今天對這些內容再做一次梳理。

ESB服務匯流排和API閘道器

注意這兩個實際上是一個層面的東西，如果SOA和微服務架構是一個層面，那麼ESB匯流排和API閘道器就是另外一個對等層面，只是ESB匯流排更加重，支援傳統異構系統協議轉換，適配，資料對映等複雜能力。而API閘道器更加輕量，重點就是透過代理實現內外網隔離，其次就是各種安全，日誌，流控攔截。

引擎和管理平臺要拆分開

這個在很早一起進行的SOA和ESB產品規劃的時候，我們就做到這一點，即ESB引擎要和ESB的管控治理平臺拆分開，ESB可以多多種方式，類似Oracle OSB，Kong API閘道器，我們自研的ESB都屬於ESB引擎的範疇。而基於引擎我們會建上層的管理平臺，這個管理平臺要做到能夠相容下面各種不同的引擎，前期我們規劃也按該思路展開進行。

管理平臺再進行二次拆分

對於管理平臺需要再進行二次拆分，即涉及到本身介面管理的內容，包括介面服務註冊，接入，安全配置等內容，這些內容和引擎繫結的很緊密，管理平臺有時候並不容易做到多引擎適配。另外一部分就是完全的服務統計，監控執行分析內容，這部分內容我們完全是基於服務執行例項日誌表展開，那麼只要服務例項表是一套，我們的執行統計分析平臺就可以做到完全複用一套。

基於以上思考，我們在傳統ESB匯流排產品規劃基礎上就開始考慮增加API閘道器子產品，API閘道器產品不是簡單的基於已有的自研ESB產品進行改造升級，而是基於當前主流的開源API閘道器產品，類似Kong閘道器進行定製開發和擴充套件，從當前趨勢也可以看到在微服務架構推廣實施下，Kong閘道器很可能成為一個主流的API閘道器產品。

因此需要考慮基於當前新架構重新擴充套件一套API閘道器產品，API閘道器本身和已有ESB產品是一種平級的引擎，只是一個輕一個重而已。關鍵的功能實現實際上都一樣。

基於API閘道器產品，我們進行上下左右擴充套件，這些擴充套件圍繞API閘道器進行。

在底層，我們擴充套件和當前我們已有的DevOps支撐平臺的整合，即任何一個微服務模組的開發不僅僅涉及到微服務元件模組，也涉及到微服務元件暴露的API介面服務，引擎API介面服務的全生命週期也可以用DevOps支撐平臺完全管理起來。

在左邊，也就是API執行的全生命週期，擴充套件API介面服務開發接入平臺，方便API介面服務的快速開發和接入，類似傳統PaaS平臺規劃的時候我們做的開發框架和環境，開發平臺提供。整個開發接入平臺，實現API介面服務的快速註冊接入，介面服務的入庫過程。

服務接入後執行在API閘道器引擎，在右邊即管理後生命週期，包括了API介面服務的後期治理管控，執行統計分析，執行監控，監控預警，服務鏈監控，服務SLA等，都屬於後生命週期內容。

在上層我們擴充套件Open API能力開放平臺，實現API介面服務的能力開放，OpenAPI能力開放平臺跟當前主流的京東，天貓的電商能力開放平臺很類似，即需要提供面向API介面服務的運營能力，實際上我們完全可以理解Open API能力開放平臺需要包括自服務流程，服務訂購，服務計量計費等能力，即一個基本電商平臺的變形。

圍繞中介軟體和技術平臺這塊，給出還是以微服務架構+DevOps支撐平臺+容器PaaS為核心，其中將API閘道器從原有的架構體系中剝離出來，即API閘道器即可以做為整個DevOps支撐平臺一部分，也可以作為獨立提供的中介軟體整合產品。

同時原有思路為在已有的ESB匯流排引擎基礎上進行改進，形成面向API介面開發，服務接入的API閘道器產品，即在ESB匯流排引擎基礎上實現API全生命週期管理，形成API閘道器子產品。而新的思路為基於類似Kong閘道器重新開發和定製高效，輕量的API閘道器產品。

這個API閘道器和ESB匯流排都屬於SOA整合中介軟體。

ESB匯流排面向傳統遺留系統較多，適配和協議轉換場景複雜的企業應用整合場景。API閘道器產品面向當前新微服務架構下的API介面服務整合和管控

同時在我們整個產品體系規劃中，為了實現產品的靈活組合，進一步對原有產品按微服務架構和元件化思路進行拆分，形成多個松耦合的子產品，可以基於使用者需求靈魂組裝我們提供的產品組合。

在原來談ESB的時候，我們已經做了第一個層面的解耦設計，即將ESB產品分為三個子產品和元件，即ESB開發設計器，ESB匯流排引擎，ESB管控治理平臺三部分內容，三者屬於松耦合關係。

在上篇文章裡面我們已經談到，ESB管控治理平臺實際包括兩個部分內容，一個是對介面全生命週期管理的內容，一個是介面例項執行的監控分析內容。當我們規劃ESB和API閘道器兩個引擎的時候可以看到，對於管理平臺部分兩個引擎差異較大，往往並不容易複用一套管理平臺，因此我們將管理平臺部分進行拆分，將可複用的服務監控分析平臺剝離出來，而對於管理平臺部分仍然保留API閘道器和ESB匯流排各自一套的做法。

OpenAPI平臺核心是已有介面能力的對外開放

對於OpenAPI平臺我們進一步單列，我們理解是ESB匯流排介面，API閘道器的介面都可以提供給OpenAPI平臺進行能力開放和對外運營。因此OpenAPI平臺更多是一個介面服務的運營平臺，那麼這個平臺就必須提供自服務門戶，服務目錄瀏覽，服務消費幫助指南，服務訂購，服務計費計量，售後問題管理，多租戶管理等一系列功能模組。

由於服務本身也是一種產品，因此一個可運營的OpenAPI平臺需要提供類似主流電商平臺一樣的標準功能模組。我們的OpenAPI平臺也一樣，完全可以基於我們已有的電商平臺進行改造和重構，而不是重頭開發。

OpenAPI平臺本身就是一個服務聚合後的能力開放平臺，那麼如果企業內部有兩套匯流排，也完全可以將各自的API介面能力全部聚合到OpenAPI平臺再進行開放和後續管理。這個時候我們看到，為了實現後續的訂購服務開通，計量計費管理功能，OpenAPI平臺應該和ESB或API閘道器引擎之間定義標準的介面整合，即兩套引擎使用一套標準的介面進行整合。

管控平臺中的自服務流程本身需要遷移到OpenAPI平臺

進一步思考可以看到，對於原來我們規劃在管控平臺中的類似服務接入流程，服務訂購流程等，需要遷移到OpenAPI平臺中，作為面向業務系統的自服務流程。如果是建立的一個大生態，還可以看到，我們原來規劃的API開發接入平臺等內容也需要遷移到OpenAPI平臺，做為業務系統自助化服務接入的一部分。即API介面的開發商不再是企業或運營方內部，而是變化為外圍生態的業務合作伙伴。

自助化的服務接入+自助化的服務訂購+服務運營能力才形成一個完整的能力開放平臺。

產品組合和產品規劃

不要單純的按個人的假設去構想產品，實際上你會發現很多產品構想的很美好，但是卻並沒有真正的市場或客戶需求，或者說你規劃產品的時候想到的使用者需求都不是真正的剛需，僅僅是一種看上去很美好的偽需求。做產品的人有時候經常會碰到一個很熟悉的場景，就是你準備創業做個什麼產品的時候，你跟身邊的朋友講，朋友們都覺得不錯，值得去做，但是真到了產品做出來，沒有一個朋友願意買單。

一個好的產品往往應該是具備透過短週期迭代進行自我造血的能力，而不是一直需要不斷的研發成本投入孵化，不斷的成本投入無盈利往往並不具備可持續性。而好的產品就是迭代版本1上線就能夠有使用者，同時透過種子使用者需求反饋不斷的推出新的迭代版本，在每一個迭代版本都具備了自我造血能力，或者簡單來說就是在早期就具備了使用者或流量資源的變現能力。

做產品規劃，即使你是做一個產品，你也應該理解為實際上是一個產品集規劃，在整個規劃裡面需要拆分不同的元件或模組，同時構建基礎的產品平臺。這樣做的目的就是在做產品的過程中積累可複用的內容，積累可靈活組裝的內容。

舉例來說你做一個APP，即使這個專案失敗了你會發現抽取的基礎平臺或資料模型還可以快速的應用到做其它業務場景應用。那麼原來的研發成本投入就可以進一步產生價值和作用。

產品規劃很多時候實際上是站在成功者的肩膀上來完成，既有模仿，更有超越。一個好的產品不是產品研發使用的技術上的超越，而是對於市場和使用者真實需求，和你需要提供的產品或服務匹配模式上的超越。對市場的洞察，對使用者真正需求的理解往往才是做出好產品的關鍵。

產品規劃不是好的商業模式規劃，但是產品規劃本身又必須得和你準備的商業模式相結合，你才能夠搞明白產品研發完成後實際產品的營銷或運營的重點在哪裡。如何透過商業模式和運營策劃來進一步採集需求，並促進產品研發本身的發展和演進。

一個產品越是做的產品化和可配置化，往往底層模型就越複雜，同時效能也就越降低。即使這樣你也很難真正滿足所有使用者不同場景下的業務需求。在當前情況下更好的策略一定不是追求100%的產品化，而是應該底層核心產品化，其它上層可以靈活定製和可配置。比如80%的產品化+20%的可配置化往往是更好的思路。

構建雲原生技術平臺

最近的工作重點就是對年初的產品規劃進行重新覆盤，並對產品規劃相關內容進行調整，給出後續產品研發目標和具體行動路線。因此會寫一線產品規劃思考方面的文章，主要還是幫助自己理清楚後續產品發展的思路，形成可以長期持續發展的產品演進路線。

經過最近的思考，比較明確的就是對於原有的ESB服務匯流排產品研發逐步朝API閘道器轉型，同時搭建基於API閘道器的SOA服務治理和監控平臺，同時構建更上層面向運營或開發商合作伙伴的能力開放平臺。雖然SpringCLoud框架體系裡面已經有類似Zuul的閘道器元件，但是整個規劃裡面我們還是將API閘道器單列出來，因為整個API閘道器不僅僅應用於微服務架構體系和對外API介面暴露，更加重要的是將成為我們後續構建能力開放和服務能力聚合平臺的一個關鍵整合平臺。即整個重點將圍繞以下兩點展開。

1. DevOps支撐平臺（提供容器化PaaS和持續整合能力）

2. API閘道器平臺和能力開放（提供最終的API全生命週期管理和後續的服務能力運營能力）

對微服務架構的支援和融合

在原來談微服務架構的文章一直在強調，微服務架構不是簡單的使用SpringCloud開發框架，更加不是簡單的提供Rest API介面服務就是微服務架構。而更加重要的是微服務模組如何拆分，微服務API介面服務如何識別，粒度如何把控。其次更加重要的是微服務框架體系如何和DevOps支撐平臺融合，如何和API閘道器整合融合，包括如何和後續的監控運維平臺融合。這些都必須考慮清楚，才能夠形成DevOps的基礎能力平臺。

同時在微服務架構實施過程中，我們有一系列的開發規範和技術標準也需要提供，包括模組的劃分設計，API介面服務識別和定義，程式碼開發，測試，資料庫拆分，安全，分散式事務處理，部署上線，監控，運維等，這些標準都必須定義清楚，否則整個微服務架構實施後由於模組拆分的更細，沒有很好的研發過程管控，技術標準約束你反而會覺得比原來單體應用開發更亂。

技術平臺構建大體系的另外一個關鍵內容

在原來談私有云PaaS平臺的時候就經常談到裡面有一個技術平臺提供類似4A，流程，安全，快取，訊息，日誌等各種技術服務能力。而在整個微服務架構體系實施中，也必須有一個完整的技術平臺，每一個技術服務就是一個獨立的微服務元件模組，可以獨立部署和管控。

技術平臺的各種技術能力，仍然是以獨立的技術服務方式提供給整個微服務架構體系中。在整個微服務架構體系裡面可以看到，內部的各個業務微服務模組呼叫技術服務API介面就不需要透過API閘道器，而直接走微服務註冊中心即可。

監控平臺-需要提供的是端到端的監控能力

對於監控平臺可以看到，需要提供從資源到服務再到應用的端到端監控能力。最底層是伺服器，資料庫，中介軟體等資源監控。上面是服務和服務鏈監控，再上面是應用監控和端到端業務流程監控。

資源，服務，應用三個層面的應用之間本身又相互影響，存在勾稽關係，一個是資源最終暴露的效能問題可以反追溯到具體的應用業務功能功能，而具體的業務流程端到端監控本身又可以詳細分析到某一個業務功能點和介面服務的效能資料。

能力開放平臺-面向對外運營和大生態建設的基礎

構建微服務開放框架，DevOps能力支撐平臺或API閘道器可以實現的內部完整的微服務架構化，而如果要做到對外運營，服務聚合和大生態體系建設，更加重要的就是能力開放平臺的建設，這個平臺最終實現內部能力的開放，外圍能力和生態的聚合，並走向產品化+運營化的發展方向。

能力開放在前面我談到過，一個是完全自身已有能力的開放，一個是構建開放平臺聚合外圍能力。而只有聚合外部能力才是構建大生態，可持續發展的關鍵。能力開放也不是簡單接入一個API介面，更加重要的是提供從能力開發接入，能力執行，能力消費訂購，能力監控運維的全生命週期管理能力。

市場驅動研發

從專案到產品，從產品到運營，估計是大部分軟體企業希望的發展軌跡，但是很多卻只能一直停留在做專案階段，或者說連做專案都算不上，只能做軟體人力外包等事情。

拿我們自己來說，前幾天對我們最近10年做的軟體專案做了下梳理和統計，發現大大小小透過做專案形成的軟體產品有20多個，而實際到現在還在不斷的進行升級維護的不超過5個，其餘的全部都沒有具備可複製性，放在配置庫的程式碼也沒有了任何價值。

一個專案形成的軟體應用如果後續不能剝離可複用元件，或者不能產品化複製，那麼對於整個公司來說就沒有任何有價值資產積累，對企業來說也無法形成可持續的盈利模式。這個也是我原來一直在強調的，企業不是賺每個員工人天報價的差價錢，而是應該賺錢產品大量複製的錢。

在IPD整合產品開發裡面，我們經常會談到一點就是市場驅動研發，市場和研發的緊密協同，而實際上對於大部分軟體企業來說，只有銷售和研發，中間缺少了關鍵的市場環節。如何來理解這個事情？

在市場環節時候，所有努力全部圍繞在我們的核心目標和產品研發上展開，不會偏離。

即我們前期是根據市場需求調研，透過對市場需求的分析來規劃我們的產品，制定產品研發迭代計劃，其次就是我們產品研發出來後是市場配合我們去做市場推廣和策劃，重點就是推我們的目標企業和目標使用者。

那麼這樣我們做的事情，研發的產品始終都會圍繞我們的目標進行。如果市場環節確實，那就變成銷售看到有專案機會就會去接，後續開發團隊也很難真正圍繞主體產品開展持續的研發投入。

而銷售型專案方式你會發現，當接一個新的專案型訂單，是定製開發方式時候，銷售在說這個專案具備可複製性，可以進行產品化孵化，而實際上根本無法產品化。

這麼多年下來，我們孵化成功的產品，或者說能夠持續研發投入不斷進行架構最佳化和功能迭代的產品最終只有兩個，即一個是我們的自研ESB產品，一個是DevOps支撐平臺，自研ESB我們做了快6年，而DevOps支撐平臺我們也做了3年，不斷的持續改進。從自研ESB到我最新的API閘道器產品，也是平滑的過渡。也正是這個原因，在最新產品規劃裡面，將DevOps平臺 API閘道器作為核心的產品進行規劃並持續演進。

當我們陷入到專案化的泥坑的時候，實際上主要是兩個方面的原因，一個就是本身的生存和現金流壓力，其次就是無法抵住高利潤的誘惑。但是對於很多專案型的專案，剛開始評估的高利潤到最後反而成了虧本專案，需求範圍的不確定，後期反覆變更，驗收的困難相信也是大部分軟體企業都面臨的問題。

產品規劃的落地和研發過程管理

產品規劃最終要落地，因此必須有後續的產品研發版本計劃，如果從半年或1年的產品規劃角度來看，需要有具體的大版本研發計劃和小版本研發規劃。大版本可能比較粗，而小版本則是需要細化到具體的需求項，週期也要控制在2到4周以內。以方便專案的監控和跟蹤管理。

研發版本計劃制定後，就有執行，就有跟蹤監控，就有研發過程管理，而最近2年由於大部分在外面做專案，發現研發過程管理這塊缺少還是比較多，即原來已有的標準化的研發過程很多都沒有繼續執行，很多過程資產也沒有進一步積累，這個本身是一種關鍵確實。即使我們現在推DevOps支撐平臺，也需要和我們的專案管理，和我們的研發過程管理，和研發支撐工具鏈緊密的整合。