單體應用架構在創業型專案里面是非常合適的，畢竟它主要的擔當還是在驗證創業模式以及迅速功能實作，所以它從開發到部署，在少量開發人員的基礎上能非常減少成本，主要是門檻低，開發效率也非常高，到目前為此，這個物聯網專案從開發開始到現在線上運行大概經歷了5個月左右的時間，訂單資料從日訂單幾百到現在的七八萬，在應用層本身來說并沒什么壓力瓶頸，中間主要升級了資料庫RDS的配置，由原來的4核8G升級到了8核16G，對資料庫稍微做了些優化，依然跑到很穩定，公司從實施想法開始，到目前半年的時間里面，不斷的總結創業思路和改變策略，所以開發的業務變化由不斷的“試誤型”開始趨向于明確“清晰型”，而且業務垂直方向也越來越深，由自己做投放商急迫需要轉型做招商平臺城市合伙人，而且廣告內容，和線下門店資訊推廣也在融合，其實和我之前的電商O2O很類似，一開始自己做個簡單交易網站賣東西，做著做著就做B2C，B2B平臺，其它的商家也進入這個平臺開網店，將線下的資訊廣告推廣也融合進來，大概套路都一樣，無非是前期自己先驗證模式，覺得可行就做平臺告訴別人應該怎么怎么做，公司在半年的時間里面也各種融資好幾輪，達到了好幾千萬級別的融資，接著而來的對軟體平臺的需求和要求也越來越高，想法誰都有，關鍵是要去實施，互聯網游戲的規則就是這樣，技術實施永遠跟著產品想法的屁股在后面追，
單體應用架構在專案這幾個月業務變化頻繁，不斷迭代的程序中，的確也出現了很多問題，最開始，業務比較簡單，你寫同一個工程里面寫代碼，我也在同一個工程里面寫代碼，測驗完畢后，我這邊就直接打成個war包(因為線上部署在tomcat的ROOT目錄里面，我有時候直接在本地tomcat的ROOT里面解壓縮成zip包)，丟到線上服務器，簡單方便，速度快的很，這種發包方式我們簡稱“全量部署”，哪怕你這次改一點點需求只動了一個類里面的一行代碼，我也是將所有的代碼打包一次，簡單業務簡單方法處理是沒有問題，隨著業務需求的累加，并且不斷的迭代，這種打包方法隱患慢慢多了起來，有幾次線上發包“全量部署”，出現之前OK的功能代碼不OK（其實這次發布不涉及到這些功能），細查之，知道開發人員提交了沒測驗的代碼，就算后面非常謹慎和寧愿操作麻煩想保持SVN代碼的“純潔性”，但是風險問題依然存在，后面一段時間，我改用了“增量部署”，就是這次改掉了哪幾個類，哪幾個檔案，在發包檔案里面一 一描述，發包的時候只去測驗好的測驗環境拿下來這幾個檔案，傳到正式環境里面，稍微控了下風險，
當然，單體應用架構本身對應用服務器的性能消耗也沒有做到很好的水平擴展，如果后期線上量大，我也只能單臺的去升級配置，越到后面升級配置越貴，當然，我們目前的業務還沒有這么夸張，但是隨著業務的擴展，肯定無法避免這些東西，另外，資料庫隨著業務的水平擴展，業務的粒度細分，也不可能所有的表都在同一個資料庫里面，這個也要求后期提前做好分庫分表的架構準備，
我們生在一個微服務四處橫行的年代，基本上屬于那種不玩單體應用架構，就玩微服務架構，不玩微服務架構，就玩單體應用架構，如果再倒退10年，可能就玩SOA面向服務企業架構，雖然和微服務最終實作的目標差不多，但是SOA表現的方式更多是以系統級別的形式表現，系統與系統的互動，所以更多的是通過傳統的webservice的呼叫來滿足按照業務的拆分，好在當今有微服務眾多的成熟框架，實作起來更加靈活簡單，而且入門也相當簡單，更主要的開發起來比SOA更加輕量級，并且這些成熟框架本身集成了微服務中需要解決的基礎共用的東西在里面，比如微服注冊與發現，路由網關，客戶端負載均衡，傳輸協議等等，話雖如此，但是真正用微服務從頭到尾開發過幾個專案的開發人員并不多，我們連續好幾個月也一直在招聘對微服務，服務化相對熟悉的人，也寥寥無幾，來面試的人可能也就是在書上看了些資料，搭建個簡單的框架，但是真正沉淀在實際業務場景用微服務開發的人員一直沒遇到，
經過再三考慮，我們決定使用springcloud來開發V2.0版本，業務拆分全部微服務化實作，V1.0單體應用架構在這段時間里會小范圍維護，集中精力大概用2，3個月時間完成V2.0版本的迭代，腦袋一蒙，后面的大把的坑在等著我們，我們也準備好了打場硬仗，
轉載請註明出處，本文鏈接：https://www.uj5u.com/qianduan/151927.html
標籤：其他
上一篇：【ODYSSEY-STM32MP157C】驅動 UART 讀取傳感器資料
下一篇：Qt移植mqtt庫