上一章，大致說了一下項目所要做的東西，以及對于框架選擇的原因。在這里繼續(xù)接下去說項目是如何一步一步的開發(fā)的。

首先需要說一點的就是，如果一個項目存粹的是為了自己公司去盈利或者為了以后發(fā)展，不是為了拿來拉融資的，可以很肯定的說，前期基本都是在砸錢，基本半年內(nèi)不用想著有收入，如果一開始就想著賺錢，那極大有可能導(dǎo)致崩盤。說白了一句就是：沉不住氣。

先說一下項目

整個項目的構(gòu)架可以分為3大模塊，商家端，小程序，AI名片后臺。由于需要考慮到版本上線以后，新版本的開發(fā)，因此需要創(chuàng)建兩個項目，一個是beta,一個是master項目，若是版本上線以后需要BUG修改，還需要建立一個bug分支。

因為這個項目我是打算從一開始就想著以后如何去更好的發(fā)展的，所以有一點是千萬不能忽視的，那就是系統(tǒng)日志的功能，針對于系統(tǒng)日志的功能，用的可以是文件存儲，當(dāng)然這種形式是可以的，但是一旦數(shù)據(jù)量大，可能會就導(dǎo)致查詢的時候反省慢，當(dāng)然也可以吧數(shù)據(jù)放數(shù)據(jù)庫，但是數(shù)據(jù)庫的弱點很明顯，他的讀取效率真的不高，而且高并發(fā)的問題也是他的一個弊病，如果用RDS的話，先不說他處理高并發(fā)的能力，他的價格就有點望洋興嘆。綜上所述，可以替代的只有mongodb，他的存取效率也快，雖然比不上redis,但是數(shù)據(jù)庫和他比肯定比不上的。因此作為日志和數(shù)據(jù)的統(tǒng)計，我基本就放在mongo里面，這樣讀取也方面。

接著就是說到接口安全性的問題了，在這邊我用是rsa加密和rsa解密來作為安全驗證，用戶在登錄的時候，通過公鑰生成一個token,然后通過每次接口調(diào)用利用token來做安全解析。其次對于請求接口獲取參數(shù)的時候，也進(jìn)行參數(shù)的驗證，為了防止惡意數(shù)據(jù)或者額外數(shù)據(jù)的進(jìn)去。

之前做過一些項目，也看過一些代碼，發(fā)現(xiàn)一個點就是針對于，分類這塊很多人使用的都是遞歸的方式去實現(xiàn)，這種方式可以很明確的說，這種方式是最耗數(shù)據(jù)庫 ，同時如果需要實現(xiàn)無限極分類，還用這種方式，直接會導(dǎo)致腦子短路，全程懵逼，一旦注入的商家多了，數(shù)據(jù)量大了，那頻繁的讀取數(shù)據(jù)庫，最終導(dǎo)致的就是，調(diào)用這個分類接口，最后耗時要N久N久。在這里可以友情推薦一種方式，距離邏輯自己可以自己考慮，就以A級為一分類，表中設(shè)置一個字段，cat_num_id? 可以設(shè)置為00001 那他的二級分類可以為00001,00001 如果在有個A級的下級分類可以為00001,00002。以此類推，可以無限極分類，當(dāng)然查詢的時候，為了保證分類是有序化的，可以直接用cat_num_id 進(jìn)行排序，最后得到的數(shù)據(jù)就是按規(guī)則上下級排列的數(shù)據(jù)。在這大致說一下思路，具體的可以慢慢摸索。

在后臺中著重需要說一下的就是一個系統(tǒng)統(tǒng)計的功能，因為這塊功能關(guān)乎于訂單系統(tǒng)，包括用戶瀏覽，用戶注冊，以及活動的統(tǒng)計，設(shè)置于說是未來如果項目發(fā)展好，考慮到大數(shù)據(jù)的分析都有著重要的作用，但是由于這塊內(nèi)容的數(shù)據(jù)量太過龐大，因此可以把統(tǒng)計數(shù)據(jù)放在mongo里面，這樣以便于減少數(shù)據(jù)庫的壓力。

其余的一些商家后來的商品增刪改查，以及訂單后期處理，活動的設(shè)置，同款商品的分類就不具體細(xì)說了，因為這個人都有自己的思維邏輯，蛋歸根一點就是在實現(xiàn)功能的前提下如何更優(yōu)化簡便的去實現(xiàn)功能，從而來減少商家的工作量。