開發(fā)一個app有多難？首先我是前端工程師，所以我用H5的東西開發(fā)app，不是原生的Android和IOS，當然也有很熱的顫振，雖然還沒有完全投入使用。所以我下面說的，只針對想開發(fā)前端app的朋友。當然

開發(fā)一個app有多難？

首先我是前端工程師，所以我用H5的東西開發(fā)app，不是原生的Android和IOS，當然也有很熱的顫振，雖然還沒有完全投入使用。所以我下面說的，只針對想開發(fā)前端app的朋友。當然，我也只是開發(fā)了幾個，還有很多經(jīng)驗不足的地方。如有文字上的問題，望指正。

其實我剛開發(fā)一年多。說實話，我感覺只是開發(fā)已經(jīng)上市的東西相對容易?，F(xiàn)在有很多成熟的框架，有很好的API可供參考，網(wǎng)上也有很多資源，很多情況下都能找到。你可能遇到過很多問題才遇到的。去官方論壇和大家交流學習。我覺得真正難的是你能不能做到，而不是想都沒想就去問一個人。我不 我不推薦這種態(tài)度。即使你的問題很簡單，結果發(fā)現(xiàn)只有兩行代碼，但這個結果也源于你之前不斷的追問，知識是你自己的。

簡單跟大家分享一下我的經(jīng)驗。第一個app是mui Logistics Handheld開發(fā)的。簡單來說就是接單后上傳信息，查找歷史列表等等。我是公司唯一的前端，項目開始前只看了梅姐一周左右。It 它實際上只是一個html頁面，但也有許多調(diào)用原生的東西。記得當時每天工作到很晚，簡單的登錄列表顯示頁面，還是很好寫的。晚上下班后留在公司查系統(tǒng)攝像頭怎么叫，二維碼怎么用，繳費催收怎么叫。我 我也很緊張。我 我獨自從頭開始做這件事。后來看到了官方集成的html5，很多都有例子，當然也會結合自己的功能做一些改動。我也加入了幾個群。雖然廢話很多，但是也有很多人在討論技術。所以資源很多，自己主動去找。后來開發(fā)的時候，開發(fā)效率很快。

那時候有個很麻煩的東西叫地圖。我是用pc和app同時做的。pc發(fā)貨，app接單，都是用高德的地圖jsapi。但事實并非如此。;我不在手機上工作，我也不 我不知道為什么。我也發(fā)現(xiàn)了很多東西，但打包的基本上都是不 t秀。我問某人 s顯示器，然后我詳細問他。他說我也是剛買的，我的可以出來。我 我太棒了。我能說什么呢？我 我會告訴自己。我清楚的記得做了三個星期，其他版面寫的很快，所以經(jīng)常做地圖。最后真的是瞎貓碰上了死耗子。我真的不知道。;不明白為什么和軟件版本什么的有關系。我沒有。;我沒有使用sdk，但是我引用了百度 的地圖sdk，和jsapi使用高德 顯示是成功的。當然，很多人會質(zhì)疑，don t糾結這個，重要的是效果一定要出來，可能是我說的容易，也可能是運氣，但這些都是建立在我自己前期努力思考和查閱資料的基礎上的。原來是看懂米。盛何復，現(xiàn)在我在實踐中了解稻盛和夫先生。

現(xiàn)在我 我使用uniapp，mui團隊開發(fā)的另一個框架，來開發(fā)一個簡化的標題。也是文章，專家，訂閱，評論等等。剛開始的時候，我慢慢看文檔，看官方的例子，開始動筆，深入到fl

如何設計一個秒殺系統(tǒng)？

說起秒殺系統(tǒng)，我們第一反應可能是電商平臺上的各種活動，12306售票系統(tǒng)等。的確，這些都涉及到秒殺的概念。

秒殺系統(tǒng)有什么特點？1.瞬時高并發(fā)，短時間內(nèi)流量峰值，用戶激增，促使網(wǎng)站流量超過上限；

2.存在超賣現(xiàn)象，成功下單的人數(shù)多于庫存；

3，業(yè)務流程簡單，沒有太多花哨的功能。

秒殺系統(tǒng)怎么設計？基于上述特征，道釘系統(tǒng)需要做到以下幾點:

1.前臺的靜態(tài)資源被CDN加速。

把JS，CSS，圖片，音視頻文件放到CDN上，以預熱的形式把資源刷新到每個CDN節(jié)點，讓用戶可以 "閱讀附近 "，加快訪問速度，減輕源服務器壓力。

2.限流

限制用戶請求，禁止同一賬號在同一時間段內(nèi)發(fā)送大量請求。

3.任務的異步處理

比如訂餐、郵件通知、短信接收等。，可以異步處理的業(yè)務必須異步處理，以避免同步阻塞。

4.合理緩存

大多數(shù)秒殺商品數(shù)據(jù)不 不需要實時更新(庫存等字段除外)。對于這種熱點數(shù)據(jù)，唐 不需要實時更新，可以放在緩存中，避免從數(shù)據(jù)庫中查詢，可以減輕數(shù)據(jù)庫的負載壓力。

5、其他業(yè)務降級

任臺的軟硬件資源都是有限的，我們可以暫停一些不重要的服務，為秒殺系統(tǒng)放棄資源。

讓 讓我們詳細討論接口層如何處理它。

上圖主要描述了后端接口在處理請求時的操作:

1.緩存數(shù)據(jù)，可以存儲當前的商品總量。如果Redis是分布式的，那么可以使用分布式鎖來解決臟數(shù)據(jù)的問題。

2、不會需要和當業(yè)務的響應進入消息隊列時。

3.定期將緩存的數(shù)據(jù)更新到數(shù)據(jù)庫。為了避免臟數(shù)據(jù)，可以采用兩種方法:悲觀鎖定和樂觀鎖定。個人建議樂觀鎖定。

4.消費消息隊列消息，根據(jù)消息類別做不同的操作。

在spike系統(tǒng)中有很多不確定性(比如請求數(shù)和并發(fā)數(shù))，所以spike系統(tǒng)可以 與監(jiān)控系統(tǒng)對各種指標的監(jiān)控分不開。發(fā)現(xiàn)異常就要融合，資源不足就要提交準備擴容。

那個 這是我的看法。你怎么看待這個問題？歡迎在下方評論區(qū)交流~我是科技領域的創(chuàng)作者，有十年互聯(lián)網(wǎng)行業(yè)經(jīng)驗。歡迎關注我了解更多科技知識！