1.以快速的產品雛形面向市場。
現在很多互聯網產品還沒有上線就已掛了。或者說上線後沒有什麼流量，產品就下線夭折了。在這個產品雛形階段我們儘量選擇
成熟的框架，傳統的企業架構模型，但也要做到功能模塊分包清晰，代碼組織結構，controller，business，dao這三層清晰，爲以後項目的重構奠定基礎。筆者在3年前也經歷過一些互聯網創業公司，那個時候scrum開發過程管理還不流行。在公司對自己想定位的產品發展思路還不是太清晰時，只會是業務需求來驅動技術架構。
2.技術框架在產品中是什麼？
有時候我看到身邊朋友不斷刻苦專研各種技術，各種技術技能也許只對程序猿在面試具有一部分含金量。其實對我們產品在市場中，客戶眼裏。不是已技術來確定價值。技術框架在產品也只是一個tools，採用開源框架對構建產品架構具有幾個優勢，1.開發成本低，大量開發人員深入掌握該技術，容易上手，可以更多關注業務。2.穩定性高，每次產品上線後都會經歷一個生產各種問題階段。對於開源技術同類問題解決方法網上有很多同例。最近幾年我們採用開源框架還是基於spring，mybatis，mysql，nosql，cache，Jquery還是基於這些。但是我們面臨的是一個大數據時代，在架構設計的思想上有了很大的變化。。
3.怎麼提供一個優秀產品架構？
當產品有一定市場基礎後，我們就要思考怎麼把產品架構設計成一個高性能，大數據，彈性，擴展性好的Cloud Service。SaaS (Soft as s Service)這種產品模式基本被很多公司所使用。引入微服務分佈式架構，微服務的有幾大從開發到運行維護的優點。
常見單體式應用的幾大缺點：
1.到項目後期功能來越複雜，app變的龐大，不利於單一團隊的敏捷開發，維護。筆者曾經親身經歷一個運營5年巨大複雜單體應用的開發維護，該app有一個baseVersion，根據不同site定製需求，後臺採用繼承overwrite來擴展定製化。前端則採用include方式，不同site提供不同subPage，採用ant編譯工具，構建不同site進行替換。第二問題，加上運營維護已經n年了，開發人員不斷的流失，對於後期加入該項目人員，學習成本非常高，也非常容易出錯。
2.單體式應用在不同模塊發生資源衝突時，擴展將會非常困難，例如需要多cpu，大內存，
3.單體式應用另外一個問題是可靠性。因爲所有模塊都運行在一個進程中，任何一個模塊中的一個bug，比如內存泄露，將會有可能弄垮整個進程。
4.單體應用不利於應用新的技術，沒有進程的隔離，害怕version confilct。
微服務架構的好處：
1.首先，通過分解巨大單體式應用爲多個服務方法解決了複雜性問題。減少團隊學習成本，溝通成本。一個團隊人數太多就難於管理。
2,第二，這種架構使得每個服務都可以有專門開發團隊來開發，也隔離技術選擇性的風險。對於後期提供服務，可以採用一些新技術。
3.第三，微服務架構模式是每個微服務獨立的部署。開發者不再需要協調其它服務部署對本服務部署升級的影響。
4.最後，微服務架構模式使得每個服務獨立擴展。根據需求選擇不同machine，multi
cpu，big memory， ssh hardDish。
這次就聊這麼多，希望後期能聊些具體工作中實際案例分析，設計問題分享。