單體應用架構在創業型專案裡面是非常合適的，畢竟它主要的擔當還是在驗證創業模式以及迅速功能實現，所以它從開發到部署，在少量開發人員的基礎上能非常減少成本，主要是門檻低，開發效率也非常高。到目前為此，這個物聯網專案從開發開始到現線上上執行大概經歷了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版本的迭代，腦袋一蒙，後面的大把的坑在等著我們，我們也準備好了打場硬仗。