單體應用架構在專案這幾個月業務變化頻繁，不斷迭代的過程中，的確也出現了很多問題。最開始，業務比較簡單，你寫同乙個工程裡面寫**，我也在同乙個工程裡面寫**，測試完畢後，我這邊就直接打成個war包(因為線上部署在tomcat的root目錄裡面，我有時候直接在本地tomcat的root裡面解壓縮成zip包)，丟到線上伺服器，簡單方便，速度快的很，這種發包方式我們簡稱「全量部署」，哪怕你這次改一點點需求只動了乙個類裡面的一行**，我也是將所有的**打包一次，簡單業務簡單方法處理是沒有問題，隨著業務需求的累加，並且不斷的迭代，這種打包方法隱患慢慢多了起來，有幾次線上發包「全量部署」，出現之前ok的功能**不ok（其實這次發布不涉及到這些功能），細查之，知道開發人員提交了沒測試的**，就算後面非常謹慎和寧願操作麻煩想保持svn**的「純潔性」，但是風險問題依然存在，後面一段時間，我改用了「增量部署」，就是這次改掉了哪幾個類，哪幾個檔案，在發包文件裡面一 一描述，發包的時候只去測試好的測試環境拿下來這幾個檔案，傳到正式環境裡面，稍微控了下風險。
當然，單體應用架構本身對應用伺服器的效能消耗也沒有做到很好的水平擴充套件，如果後期線上量大，我也只能單台的去公升級配置，越到後面公升級配置越貴，當然，我們目前的業務還沒有這麼誇張，但是隨著業務的擴充套件，肯定無法避免這些東西。另外，資料庫隨著業務的水平擴充套件，業務的粒度細分，也不可能所有的表都在同乙個資料庫裡面，這個也要求後期提前做好分庫分表的架構準備。
我們生在乙個微服務四處橫行的年代，基本上屬於那種不玩單體應用架構，就玩微服務架構，不玩微服務架構，就玩單體應用架構。如果再倒退10年，可能就玩soa面向服務企業架構，雖然和微服務最終實現的目標差不多，但是soa表現的方式更多是以系統級別的形式表現，系統與系統的互動，所以更多的是通過傳統的webservice的呼叫來滿足按照業務的拆分。好在當今有微服務眾多的成熟框架，實現起來更加靈活簡單，而且入門也相當簡單，更主要的開發起來比soa更加輕量級。並且這些成熟框架本身整合了微服務中需要解決的基礎共用的東西在裡面，比如微服註冊與發現，路由閘道器，客戶端負載均衡，傳輸協議等等。話雖如此，但是真正用微服務從頭到尾開發過幾個專案的開發人員並不多，我們連續好幾個月也一直在招聘對微服務，服務化相對熟悉的人，也寥寥無幾，來面試的人可能也就是在書上看了些資料，搭建個簡單的框架，但是真正沉澱在實際業務場景用微服務開發的人員一直沒遇到。
經過再三考慮，我們決定使用springcloud來開發v2.0版本，業務拆分全部微服務化實現，v1.0單體應用架構在這段時間裡會小範圍維護，集中精力大概用2，3個月時間完成v2.0版本的迭代，腦袋一蒙，後面的大把的坑在等著我們，我們也準備好了打場硬仗。
我的物聯網專案之推廣策略
這個裡面從最開始推廣入口來說，現在想來其實有點意淫，也正是我前面所說，路要走過才知道，我們現在就走趟雷。推廣人員全部由外面兼職或者全職做為主力軍，當初給他們的政策就是成功推廣一輛搖搖車提成50元 聽說有時候具體情況也有提成100元的 很多推廣人員看到這麼高的利潤，著實掄起衣袖實幹了一把。注意，這個裡...
我的物聯網專案之線下之戰
搖搖車這個行業在中國至少已經存在了7，8年以上，這期間也越來越多的投放商加入到這個隊伍裡面，說明這個行業本身是剛性需求，不要小看這一塊錢現金流，如果投放的數量達到一定程度，每天的現金收入是非常可觀的。這麼來算 粗略的算 投放100輛車出去，每輛車每天消費15次也就是說每天賺15塊錢，每天總收入有15...
我的物聯網專案 七 前期線上事故
一 mqtt連線數報警 有天下午快下班的時候，突然mqtt不斷報警，手機上5秒一次收到報警簡訊，提示mqtt連線數已經超標 用阿里雲的產品感覺這塊的預警功提示的還是蠻及時 因為當初也有一些搖搖車在做測試，頻繁的使用到mqtt，所以當時也沒太在意，叫測試人員先停一下在做測試 這個裡面很尷尬，搖搖車掃碼...