一個系統會劃分前端與後端，前端是用戶看到的，可操作的可視化界面。後端是用戶看不到的，負責處理業務邏輯，數據存儲的。
在系統發展的早期，我們一般都是以單體模式出現。
單體模式優點：
随着需求越來越多，功能越來越複雜，單體模式的弊端就會暴露出來了。
單體模式缺點：
由于單體模式長遠來看明顯弊大于利，所以程序員就開始思考如何有規劃的寫代碼。
MVCMVC全名是Model View Controller，是模型(model)－視圖(view)－控制器(controller)的縮寫，一種軟件設計典範，用一種業務邏輯、數據、界面顯示分離的方法組織代碼。
MVC是從代碼意義的層面出發，将代碼分為了負責調度用的Controller控制器、負責業務邏輯和數據庫處理的Model模型、負責最終數據呈現的View視圖三部分。
相對于最開始的“一鍋粥”的混沌狀态，現在代碼間有了一些邊界，程序員分工、代碼定位也更清晰了。
模塊化與分布式MVC解決了代碼内部管理的不少問題，但是從整個系統的視角來看，依然是一個單體。随着業務規模越來越大，某幾個功能的流量可能占用了服務器絕大部分資源，于是就産生了兩個問題：
聰明的程序員就想到，把關鍵的業務邏輯和主系統剝離開來，形成獨立的模塊，這樣關鍵邏輯就能單獨運作，不受系統其它邏輯故障的影響。當該模塊用戶量多的時候，還可以把模塊多複制幾份同時運行，這樣其中一個模塊不幸挂了，那麼其他模塊還能接替他繼續運作。
把多個模塊放在同一台服務上，并沒有解決服務器處理能力極限的問題，于是就找老闆要為這台服務器升級配置，結果一出價格，吓得老闆直哆嗦。
配置提高一點，價格就高了很多，花同樣的錢能買好幾台原來配置一樣的機器。如果改成買多幾台機器，然後想辦法讓這些機器處理能力能疊在一起，性能還可以遠超升級的配置。
于是就有了分布式的誕生，多買幾台幾台服務器，讓他們同時工作。服務器還可以選擇部署在全國不同的地方，實現了用戶的就近區域訪問，讓不同地區用戶都能享受最佳的訪問速度。
微服務分布式的架構看似幫程序員們解決了很多的問題，但是新的問題又随之而來：
微服務的到來，就為這些問題打開了新思路
微服務架構是一種架構模式，它提倡将單一應用程序劃分成一組小的服務，服務之間互相協調、互相配合，為用戶提供最終價值。每個服務運行在其獨立的進程中，服務與服務間采用輕量級的通信機制互相協作（通常是基于HTTP協議的RESTful API）。每個服務都圍繞着具體業務進行構建，并且能夠被獨立的部署到生産環境、類生産環境等。
微服務中有幾個關鍵啟：
馬爾文·康威1967提出的：“設計系統的架構受制于産生這些設計的組織的溝通結構。”通俗的來講：産品必然是其（人員）組織溝通結構的縮影。
微服務架構
微服務其實是對模塊化和分布式的一種升級。
首先，後端增加了統一的“門面”——網關。
有了網關之後，前端就不需要知道衆多的服務他們分布在哪裡，隻需要請求網關，由網關将需求傳遞到相應的服務中。網關還能自動幫前端找到最快且穩定的服務節點，讓前端體驗更勝一籌。
諸多的服務分散在不同的地方，為了将這些服務組織管理起來，知道他們用途、狀态信息，避免後續發展成一共有多少個服務都無法統計，就誕生了服務池的“管理機構”。所有服務都必須在管理機構内注冊登記、及時上報自身情況。
稍微複雜點的功能，都需要多個服務互相配合才能完成的。
單體模式時代，由于隻有一套系統，程序員順藤摸瓜就能找到bug出在哪。現在存在多個獨立的服務，程序員必須每個服務逐一排查故障，這就讓找bug根源問題變得非常困難，于是就需要一套故障追蹤機制，記錄前端請求在後端實現的全鍊路，以便發現問題出在哪。
微服務實踐為了讓程序員可以更好将系統架構向微服務遷移，于是就衍生出了微服務的代碼框架，其中比較出名的方案有SpringCloud、Dubbo兩家，我們來簡單看看他們他們的官方示例圖。
從SpringCloud的架構中不難看出微服務的相對于原有的分布式架構的新特征：
微服務不是某種新技術，更像是技術架構的一種新思想，一種正在不斷疊代的、用業務的思想解決技術問題的思路。業務驅動下産生的微服務，無疑讓寫代碼這件事變得更具挑戰性，但卻讓程序更能直接表達其價值，能讓企業的業務更好、更快的發展。
業務驅動微服務研發工作流
當我們讨論産品方案時，都不能脫離業務，業務是需求最重要的根源，那到底什麼是業務呢？
從詞語定義來說，業務是指某個行業或者某個職務所做的事情，就叫做“業務”，其參與者是人，未來也可能是電腦、機器（AI、自動化），其目的滿足行業、職務的服務對象的需要。
業務方在工作過程中，為了實現更高的産能、獲得更高的回報，就會想辦法去優化整個業務流程，這就産生了“需求”。隻要業務想發展、在發展，需求就會源源不斷的産生。
産品經理接觸的需求來源，外部是業務的服務對象：用戶；内部則是業務的執行方：老闆、運營、商務、财務、法務、供應商等。業務方将需求告知産品經理，産品經理經過調研論證，将需求轉換為産品方案，輸出可以滿足業務需求的産品需求文檔、原型。
然後，産品将功能的需求提給研發人員，研發最終将這些功能得以實現，于是系統誕生了。業務方使用系統，不斷發展擴大，産生更多的新需求，于是以此往複，形成業務-産品-研發的需求鍊條閉環。
在這個鍊條閉環裡，業務形态、流程決定了系統最終的形态，而系統形态則推動業務的發展。産品是連接業務與系統的紐帶，技術并不是在瞎逛，而是根據産品的需求去研發系統，技術研發出來的系統會最終決定業務未來的走向。
架構轉變
服務是技術讓代碼更适應業務發展的産物，是業務驅動下的産物。
微服務的概念需要程序員更了解業務的闆塊劃分和發展方向，代碼要随着業務的不斷成熟，按照業務結構進行模塊化、服務化，才能方便業務的發展壯大，這就要求程序員要“懂點産品”。
如果程序員一味的按照純粹的技術方案或者自己拍腦袋定的方向做，那随着業務的疊代發展，很容易出現“這個需求做不了”的問題，因為代碼被技術方案禁锢住了，無法适應業務的發展，如果要解決，可能就要重構，時間、人力成本将居高不下。
業務驅動的過程，不是一個“理想”、“理性”的過程，代碼講究的是邏輯，是要“不出bug”、“跑得起來”，但是業務的發展是用戶、市場需求不斷積累的一個過程，很多需求可能是很主觀的，甚至有時候是“靈光一閃而過”的。需求存在不确定性，這就讓程序員犯難了，那到底要不要按照這個方向做呢？萬一做了用不上要推倒重來怎麼辦？
這時候就體現出了産品經理與技術人員的協調作用，以及對現有業務架構的劃分、對新需求的判斷和歸類，這将直接影響微服務的架構模塊。
也就是說在微服務架構下，業務人員不隻要懂業務，還要懂點技術；技術人員不隻要懂技術，還要懂點業務。
産品藍圖百度複制過來的藍圖，僅參考
産品藍圖和功能架構圖十分相似？其實表現上差不多，但是産品藍圖還包含了對整套系統的發展方向預期，裡面的很多模塊可能處于“會有的”狀态，随着業務的發展不斷補全。
有了産品藍圖後，新需求就可以很方便的進行歸類，做版本規劃時也可以看得出距離預期目标還有哪些沒有實現的地方，然後進行補齊。
更重要的是，産品藍圖作為産品設計方向的指導作用，能讓技術對産品未來的完整形态一目了然，然後再進行以業務為驅動的代碼服務化，這樣就能讓代碼能适應更長遠的發展需要，避免盲目設計導緻最終影響業務發展、需要推倒重來。
通過産品藍圖、産品規劃，産品經理能讓技術了解整個業務的未來發展方向，讓技術可以更熟悉産品，知道“為什麼這麼做”、“以後還要做什麼”，這樣在寫代碼的時候可以更有方向的做兼容。
總結微服務其實是技術、産品的目标一緻化的必然結果，大家都以如何更好的發展業務去進行工作。
産品經理可以不需要深入了解微服務下各種配套的機制、利弊的問題，但需要知道，微服務其實是産品架構在代碼層的映射、體現。
一個好的産品架構，将有利于技術框架的成型和發展，反之一個模糊不清、結構混亂的産品架構，将會讓技術也無從下手，隻能頭痛醫頭的解決眼前的需求，無法從代碼層面做長遠的兼容、發展考慮。
所以我的觀點是，微服務是技術架構适應業務發展的一個過程，如果從技術的工作上看，讓代碼順應業務的發展其實是個大難事，關愛程序猿人人有責。而産品經理雖然不需要知道微服務的技術細節和實現方法，但應該更多的強化自己的産品能力，多将業務發展方向的事情與技術同事聊聊、科普一下，有利于技術架構更好的發展。
,更多精彩资讯请关注tft每日頭條，我们将持续为您更新最新资讯!
zpostcode 
Recruit 
weather 
mreligion 
Yellowpages 
sport 
constellation 
shopping 
name 
game 
directory 
literature 
Word 
tour 
furnish 
Lottery 
tftnews 
lyrics 
News 
digital 
car 
dir 
Edu 
Finance 
