開頭先來個小故事：張三是一個程序員，在金九銀十的季節(jié)去了一家新公司就職。新的公司看起來前景不錯，做的產(chǎn)品也屬于行業(yè)前沿，張三發(fā)誓自己要在此一展鴻圖，用自己精湛的開發(fā)技術為公司的上市添磚加瓦。
張三就職的第一天，公司就開放了代碼的權限，他熟悉起公司的核心項目。結果卻驚呆了，張三發(fā)現(xiàn)公司的項目就像是一個垃圾場，各種代碼堆成山，而他要做的事情，就是去維護這些老項目，在那一刻，張三內心的幻想瞬間破滅。
但在維護了一段時間項目之后，事情出現(xiàn)了轉機。有一天，新項目下來，老板任命張三為負責人，他內心狂喜，終于可以證明自己了。
"我一定要讓代碼顯得優(yōu)雅，跟爛代碼說再見。"
剛開始，張三用了各種設計模式，瘋狂抽象業(yè)務，越做越有勁，感覺一身的才學終于有了展示的機會。但項目是多人合作的，隨著時間的流逝，和項目的不斷迭代，很多新人不再按照預定的規(guī)范來開發(fā)代碼。
為了方便，微服務如雨后春筍般一個個往外面冒，開發(fā)人員在代碼里填充了一個又一個if語句。于是，張三開始手動地限制那些不符合規(guī)范的代碼提交。可是項目時間的壓力越來越大，張三最終迫于交付壓力又放開了限制。雖然項目順利的交付完成，但是奇怪的代碼卻永久的留在了項目中。
慢慢的，原始精美的設計開始變得越來越臃腫，邏輯變得復雜無比。沒有人敢去重構，也不可能重構了。終于，張三實在無法忍受，辭職去了一家新公司就職，新的公司看起來前景不錯，做的內容也是行業(yè)前沿的產(chǎn)品，張三再次發(fā)誓自己要在新公司一展鴻圖，用自己精湛的開發(fā)技術為公司的上市添磚加瓦...
這樣的故事在互聯(lián)網(wǎng)行業(yè)內一遍一遍地上演，似乎任何項目隨著時間演進，一個個補丁打到最后都會變成“屎山型”項目，充斥著各種歷史遺留問題，新功能開發(fā)越來越慢，最終無法演進走向項目的終結。有些互聯(lián)網(wǎng)公司會為延長項目的生命周期，在某個節(jié)點聘請資深的軟件架構師，他們往往熟讀《重構》，用各種各樣的技術手段去延緩這個過程。
產(chǎn)品架構是啥
像軟件架構一樣，產(chǎn)品設計也是有架構的。
在做項目的時候，我們覺得從技術上，所有的問題都能得到解決，但是整個項目卻在不知不覺間一步步的走向“屎山型”項目。按照研發(fā)的思維，問題的根源是抽象還不夠，技術水平不行，需要更強大的架構師來重構。
聘請了資深的軟件架構師后，一開始項目似乎變得好了一些，但最終結果并沒有發(fā)生改變，只是延緩了而已，到了某個階段也只能拋棄，重新開始。
復盤后會發(fā)現(xiàn)，我們的主要精力都在解決技術上的問題，而忽略了產(chǎn)品層面。按照網(wǎng)上的一種說法，產(chǎn)品架構就是在充分理解產(chǎn)品用戶需求基礎上對產(chǎn)品數(shù)據(jù)流轉的邏輯梳理。
而我對產(chǎn)品架構的理解是從"理念世界"開始的。編程是用計算機能夠理解的語言來描述現(xiàn)實事物，計算機能夠理解的語言是什么？是邏輯。在編程的時候，研發(fā)人員需要在腦海中構思出事件的全貌，并且用邏輯的語言將它描述出來。
在西方的哲學里面有一個"理念世界"的說法，大概意思是人們做的任何事情，都是在腦海中預先構建出事物的本體，再到現(xiàn)實中對預先構建的內容進行模仿。這與我們編程的過程很相似，那么產(chǎn)品是否也遵循這個過程？
回想起以前做項目時的思考方式，發(fā)現(xiàn)確實如此，我們或多或少都需要在腦海中構建出產(chǎn)品的運行軌跡。但是在做項目的時候，作為研發(fā)的我們都在想如何用技術解決問題，卻忽略了更重要的東西，任何產(chǎn)品都是為了解決客戶的問題而存在，解決客戶的問題是根本，無論用什么手段......
如何設計產(chǎn)品架構
在設計之前，先解決人的問題，什么樣的人適合做產(chǎn)品架構？
產(chǎn)品架構就是在充分理解產(chǎn)品用戶需求基礎上對產(chǎn)品數(shù)據(jù)流轉的邏輯梳理。
所以這個人需要具備以下素質：
· 能夠調研并理解用戶需求的能力
· 能夠知道產(chǎn)品的核心價值
· 能夠理解產(chǎn)品運行原理
· 面向對象設計思維
有了這些素質，就可以開始構建"理念世界"了。
構建理念世界
構建"理念世界"其實就是將現(xiàn)實中將要發(fā)生的事情，用面向對象設計思維將事情轉換成純粹的邏輯描述，這個過程叫抽象。
舉個例子，如果我們需要做一個流量治理類型的產(chǎn)品，抽象過程大概是這樣的：流量治理基本分為2個大的內容，流量監(jiān)控和流量管理，這是核心價值。
而傳統(tǒng)的流量治理工具基本都是采用SDK的方式實現(xiàn)，它們普遍具有以下的問題：
· 侵入性強
· 治理功能不全
· 內容多、門檻高
· 中間件演變困難
· 版本碎片化嚴重
· 升級成本高
如果能解決此類型的問題，將會使得服務網(wǎng)格在流量治理解決方案上會優(yōu)于SDK的方式，這是比較優(yōu)勢。
有了上面的分析，可以得出：如果希望產(chǎn)品可以快速升級且侵入性弱，勢必不能與客戶的代碼進行強綁定，需要一種與語言無關，又能夠做到流量監(jiān)控，流量管理的手段，只能去操作系統(tǒng)上面找。
如果能操縱操作系統(tǒng)上的某些功能，使得流量在進入服務之前，先進入編寫的程序中，就做到了語言無關。
思路大概是這樣:一個請求進來，先被操作系統(tǒng)轉發(fā)到編寫的程序中，然后我們自己編寫的程序會將數(shù)據(jù)上報到某個東西保存起來，最后程序轉發(fā)到真正的服務中，流量監(jiān)控就做完了。同時，還需要一個用于存儲上報數(shù)據(jù)的東西，它需要具備持久化的能力。
在這個流程當中，使用了一種設計模式，叫sidecar模式，就用sidecar稱呼我們自己編寫的程序好了，存儲的那個就叫數(shù)據(jù)庫。
接下來推導一下流量控制的邏輯，要做到流量控制，需要用到sidecar，畢竟流量已經(jīng)被操作系統(tǒng)轉發(fā)到了sidecar上面，我們可以做過處理之后再轉發(fā)到真正的服務當中。那么就需要一個另外的東西，它來告訴sidecar要怎么對流量進行處理，畢竟每個sidecar需要處理的東西是不同的，而且策略內容需要持久化，不然找不到與sidecar的對應關系，這個東西叫做控制端。
所以流程大概變成：控制端配置流量控制策略，控制端將策略下發(fā)到sidecar上，一個流量請求過來，被操縱系統(tǒng)轉發(fā)到sidecar，sidecar先上報流量數(shù)據(jù)到數(shù)據(jù)庫，然后根據(jù)流量策略對流量進行處理，最后將請求轉發(fā)到真正的服務中。
在完全理想的狀態(tài)下，通過這樣一個流程，基本實現(xiàn)了流量治理的核心能力，并且這個流程相比SDK的方式更具有優(yōu)勢，這就是所謂"理念世界"的構建過程，純粹的邏輯描述。
驗證理念世界
"理念世界"是否正確的唯一衡量標準是它是否完全正確的描述了現(xiàn)實，就像面向對象思維里面的類和對象的關系，"理念世界"是對現(xiàn)實的抽象。
要想知道抽象的好不好，有一個非常有效的辦法。隨便找?guī)讉€人，把你的邏輯說一遍，如果表述的過程是順暢的，對方能夠理解并且沒有感覺到邏輯上的遺漏，這個抽象就是比較好的。
在做項目的時候，可以把這個過程盡量的描述給不同崗位的人，一邊加深團隊成員對產(chǎn)品的理解，一邊又通過不斷的表述來完善這個流程沒有考慮完善的內容。
如何落地
當"理念世界"被建立，就需要在現(xiàn)實中對它進行模仿，在軟件工程學當中，這一步就要開始脫離設計，到實操的階段。一般項目分2類，一類是從零開始，一類是存量項目。
從零開始的項目
從零開始的項目在動手之前，一般會面臨2個問題，從哪開始？要模仿到什么程度？
通過流程可以發(fā)現(xiàn)以下是一切的基石。
1.操縱操作系統(tǒng)上的某些功能，使得流量在進入服務之前，先進入我們編寫的sidecar中
2.sidecar
3.數(shù)據(jù)庫
所以在沒有外部特殊情況干擾的時候流量監(jiān)控功能肯定要優(yōu)先于流量控制功能做，這是從哪開始。
至于做到什么程度主要依托于時間，人員的關系，看實際情況把握。但無論做多少，只要方向是對的，對整個 產(chǎn)品的迭代都是具有正向的意義。
通過這張圖，服務劃分變得很清楚，在交給研發(fā)時，每個服務的邊界也有明確的規(guī)定。就算研發(fā)人員出現(xiàn)新入職或者水平良莠不齊的現(xiàn)象，在這個框架內所能造成的破壞力也有限，不會對整個產(chǎn)品造成結構性的問題，在未來的某個時候只需要找一個足夠強的研發(fā)重新寫一遍，問題就都解決了。
存量項目
存量項目的落地就十分的復雜，歷史遺留害人不淺......
大的思路應該是先用"抽象"映照現(xiàn)實，看看到底現(xiàn)在的代碼是否完全符合"抽象"的"流程"，先搞清楚現(xiàn)狀再想辦法修枝剪葉。
如果有新的需求到來時，還是要先抽象，任何正當?shù)男枨蠖际欠线壿嫷模绻橄蟪鰜聿环线壿?，那肯定是需求挖掘的不夠，不能盲目的加代碼。
還是那個例子，如果需要添加一個對sidecar的監(jiān)控，那流程就會變成這樣。
但是監(jiān)控單獨拎出來是否有必要？如果沒有必要的話流程可以變成這樣。
這2種形態(tài)沒有優(yōu)劣之分，可以結合具體情況做選擇。
總結
如果有了解到服務網(wǎng)格領域的朋友應該很早就發(fā)現(xiàn)，上訴說的例子就是一個弱雞版Istio的誕生。
我嘗試著從需求出發(fā)，純粹的邏輯推導Istio的架構。很多有名的開源項目為什么歷經(jīng)這么多年，反而越來越精煉，這里面一定有值得探討的地方。
本文只是提供一種解決問題的方法，解決問題的核心還得看人，一群大佬，無論用什么方法做出來的東西都精美而優(yōu)雅。
SolarMesh（服務網(wǎng)格），高效可視化微服務治理平臺，基于 Istio 及容器技術，提供應用生命周期管理、全面流量管理和非侵入式的服務治理解決方案。SolarMesh 幫助企業(yè)在紛繁復雜的微服務調度中快速定位問題，增強研發(fā)效率。讓服務網(wǎng)格不再難學難用，讓服務網(wǎng)格在企業(yè)落地更加平滑、安全、穩(wěn)定。
SolarMesh（服務網(wǎng)格）在線體驗>>
(在線體驗賬密：admin/admin)
讓企業(yè)都能高效創(chuàng)新
企業(yè)云原生數(shù)字化創(chuàng)新平臺CloudOS?
可插拔云原生工具集Cloud Native Toolkit
開發(fā)者專屬一站式在線服務Methodot
