產品經理需了解的技術架構

1、產品經理需了解的技術架構做產品經理，經常會聽到一個詞叫做：產品框架，基于業(yè)務的變 化，設計出符合用戶生命周期的產品?？墒钱a品框架式是離不開開發(fā)技術基礎的，否那么產品框架只是一 個空紙，比方是當用戶量逐漸上升，所提高得服務對性能得要求越來 越高，否那么用戶的體驗會越來越差。最有趣的案例是為什么當初米聊在用戶增長后后面在輸給了微信的 關系，騰訊有QQ先天的高并發(fā)優(yōu)勢經驗，而作為小米剛起步無論是 在經驗還是硬件上都沒有這樣的經驗，在高并發(fā)狀態(tài)下，硬件本錢可 以成指數型增長。后面在采訪中雷軍也提到：“這是他們應該賺的錢，我們不擅長”。高并發(fā)帶來的性能與硬件要求一、開發(fā)語言的知識了解同時產品研發(fā)中，因為

2、市面的業(yè)務關系會選擇不同的語音作為開 發(fā)語言，市面上主要是C、PHP、java等為主c語言主要用于那些對效率要求很高的地方，比方說電腦的各種驅動程 序，或者機械制造方面的應用。java語言桌面應用的j2se,企業(yè)應用j2ee,手機應用j2me。桌面應用的 話，可以寫一些小游戲：貪吃蛇、俄羅斯方塊等，后綴名是.jar。企 業(yè)應用的話，就是說公司里面用的一些管理軟件，網站也可以，我記 得好像校內網就是用java做的。PHP語言主要應用于Web開發(fā)領域，這兩門編程語言在應用場景上幾乎沒 有交叉，所以也相比照擬好選擇。當然以上并不是要求產品經理要去從事研發(fā)工作，但最好的方式 是經驗積累，比方是多和后端

3、開發(fā)溝通，在多個案例后逐漸不同語言 的開發(fā)優(yōu)勢二、什么是技術架構架構就是對系統(tǒng)中的實體以及實體之間的關系所進行的抽象描 述，是一系列的決策，架構也是產品的結構和愿景。系統(tǒng)架構是概念的表達，是對物/信息的功能與形式元素之間的 對應情況所做的分配，是對元素之間的關系以及元素同周邊環(huán)境之間 的關系所做的定義。做好架構是個復雜的任務，也是個很大的話題，本篇就不做深入 了。有了架構之后，就需要讓干系人理解、遵循相關決策。L架構的種類架構可以分為邏輯架構、物理架構、系統(tǒng)架構.邏輯架構：軟件系統(tǒng)當中的各個元件之間所存在的關系，比方外部系統(tǒng)接口、用戶潔面、商業(yè)邏輯元件、數據庫等物理架構：軟件元件分布式系統(tǒng)的物

4、理架構，所有元件都是屬于 物理設備，住的是有主機、整合服務器、英語服務器、代理服務器、 存儲服務器、報表服務器web服務器、網絡分流器等。系統(tǒng)架構：基于各個不同的角度進行分析，都能夠了解到劃分元 件、決定設計這個兩個架構的要素.架構圖系統(tǒng)架構圖是為了抽象地表示軟件系統(tǒng)的整體輪廓和各個組件 之間的相互關系和約束邊界，以及軟件系統(tǒng)的物理部署和軟件系統(tǒng)的 演進方向的整體視圖。一圖勝千言。要讓干系人理解、遵循架構決策， 就需要把架構信息傳遞出去。架構圖就是一個很好的載體。那么，畫 架構圖是為了：1.場景圖表用戶描述系統(tǒng)的參與者與功能用例之間的關系沒反響系統(tǒng)的最 終需求和交互設計2.邏輯圖表用于描述系統(tǒng)

5、軟件功能拆解后的組件關系，組件約束和邊界，反 應系統(tǒng)整體組成與系統(tǒng)如何構建的過程，通常由UML的組件圖和類圖 來表示。3. 3.物理圖表用于描述系統(tǒng)的軟件到物理硬件的映射關系，反映出系統(tǒng)的組件 是如何部署到一組可計算機器節(jié)點上，用于知道軟件系統(tǒng)部署實施過程。3. 4.處理流程圖表處理流程試圖用于描述系統(tǒng)軟件組件之間的通信時序，數據的輸 入輸出反響系統(tǒng)的功能流程與數據流程，通常由時許圖和流程圖表示。3. 5.開發(fā)圖表開發(fā)圖用于描述系統(tǒng)的模塊劃分和組成以及細化到內部包的組 成設計，服務于開發(fā)人員，反映系統(tǒng)開發(fā)實施過程。四、單體應用和微服務同樣的，在早期大局部應用不會考慮到技術架構，但隨著用戶增 加

6、和未來性能要求那么需要重構，這就需要到技術資深的架構師。而市 面上的架構主要分為下面三類一個單體應用程序：就是應用程序的全部功能被一起打包作為單個單元或應用程序.這個單元可以是JAR、WAR、EAR,或其他一些歸檔格式，但其全部集成 在一個單一的單元.微服務：微服務是一個新興的軟件架構，就是把一個大型的單個應用 程序和服務拆分為數十個的支持微服務。一個微服務的策略可以讓工 作變得更為簡便，它可擴展單個組件而不是整個的應用程序堆棧，從 而滿足服務等級協(xié)議。單體應用優(yōu)點：.方便調試，代碼都在一起；.沒有分布式開銷，所有服務都在本地容器內；.中小型工程可以快速迭代，不需要太多資源。單體應用缺點：.可復用性差：服務被打包在應用中，功能不易復用；.系統(tǒng)啟動慢，一個進程包含了所有的業(yè)務邏輯，涉及到的啟動模塊 過多，導致系統(tǒng)的啟動、重啟時間周期過長。.線上問題修復周期長；任何一個線上問題修復需要對整個應用系統(tǒng) 進行全面升級。微服務架構的優(yōu)點.分而治之;單個服務功能內聚，復雜性低；方便團隊的拆分和管理；.單獨部署，獨立開發(fā)；微服務架構的缺點1.開發(fā)難度大;垮服務的調用通常是不同的機器， 甚至是不同的機房，開