健康碼無法開啟，頁面點選***後出現空白。
部分情況出現502bad gateway。
核酸報告系統出現問題，結果無法顯示。
恢復的過程**現中國電信手機網路可以開啟健康碼，中國移動不可以的情況。
對於「西安一碼通」出現的故障問題，10餘位來自鵝廠、華為、中興、ict資料分析的雲著君從前端、後端、測試問題進行了原因分析。
（一）主要問題
1.限流問題：市民在長時間無法刷出健康碼的情況下，多次退出重新整理重試，新的流量到達伺服器，導致伺服器壓力變大、承受負載增加，說明「西安一碼通」系統沒有做好限流措施。
伺服器問題：無論是企業和個人在租用伺服器的時候都會受到峰值承受限制的，一旦超過伺服器的承受能力，就會導致伺服器癱瘓，應用程式暫停，**無法訪問。伺服器是有峰值限制的，不可能承受無上限的併發能力。而造成伺服器癱瘓的原因就是在同一段時間內，訪問人數多，造成高流量的突進，超出了伺服器的承受範圍。
架構問題：「西安一碼通」功能影響「核酸檢測」服務，說明模組間從介面到資料呼叫互相影響，可能不是微服務架構。
場景問題：
猜測上班高峰期大家都在訪問同乙個服務導致伺服器瞬時訪問流量飆公升，資料庫效能也跟不上，最終整個「西安一碼通」服務掛了，可能之前設計的時候沒有考慮過這種場景。
設計漏洞：沒有考慮高流量高負載的情況，導致測試不充分；產品設計未考慮千萬級的併發訪問，交付前未進行同等級的壓力測試。
壓力測試：在市民長時間無法看到健康碼的情況下，多次退出重新整理重試，新的流量到達伺服器，導致伺服器壓力變大、承受負載增加。說明壓力測試不夠。
（二）其他問題
初步推測是nginx後台的應用伺服器高併發下掛掉，懷疑是快取擊穿，導致後台資料庫響應時間變長，前台長時間無法響應。
對於中國電信網路訊號可以開啟，中國流動網路訊號無法開啟的情況，不同的運營商走的dns系統不同，因為「西安一碼通」系統電信公司有參與，所以dns指向新的ip生效最快。
該問題反應出在目前國內外疫情仍然嚴重的背景下，「「西安一碼通」」相關系統的災備建設仍不充分。未進行故障隔離和流控處理，運維預案和彈性伸縮能力不足，sla處理時長超過12h,各個服務廠商只能處理本服務問題，聯合定位協調不及時。
處理器可靠性測試包括測試標準可能存在問題，用於計算的cpu部分是否預留了合理的margin。
傾向於是硬體負載均衡器f5故障，不知道有沒有gateway-service，在gw做限流，當然應該在高防的後面waf做一下安全策略來保證系統的高可用ha，另外早高峰可以採用mq進行非同步消峰處理。（猜測沒有gateway，若有bff層，也不會這麼慘）。
（一）產品建議
進行業務剝離將小程式內業務關聯度比較高的模組獨立化。
（二）系統建議
快速響應短期建議：
（2）訪問節流：
短時間內多次請求可做防抖機制；
核酸結果是24小時(或更長或更短)內不變，建議做快取機制，24小時候間隔後再次訪問強制重新整理，介面可帶時間戳引數；
非關鍵渲染資料延遲請求，即發起乙個聚合介面請求來獲取主體模組的資料，而非主體模組的資料則從另乙個介面獲取，通過拆分的手段來降低主介面的呼叫時延；
介面聚合，請求合併，減少併發；
減少介面通訊資料，傳輸的資料量越多，執行緒間通訊的耗時越長，渲染速度就越慢；
剝離並建立非同步無關聯性併發請求；
專案穩定長期建議：
（1）業務抽象，模組剝離，獨立業務模型，行成高內聚低耦合的可擴充套件性
產品；（2）資料模型，盡可能結構關係單一，快速響應**；
（3）介面隔離，多個請求間單一職責；
（4）微前端搭建多個模組，行成模組隔離；獨立部署，分開運營；
（5）沉澱元件並復用，減少專案體積；
（6）建立中臺，減少直接請求後台資料；
（7）應用層資料加diff演算法，去掉不必要且無改動的資料渲染，加快渲染時間。
（8）崩潰預警，可讓相關開發人員快速上線響應。
系統設計建議：
（1）架構設計：業務抽象，模組剝離，獨立業務模型、資料模型，盡可能結構關係單一，介面隔離獨立部署，分開運營。
（2）雲原生：應該盡早做微服務化改造，技術中臺，服務網格化，雲原生彈性伸縮（k8s），盡快實現抽象，沉澱，復用，提高系統sla，由於「西安一碼通」資訊的特殊性建議使用私有雲。
（3）中介軟體選型：資料庫可以採用tidb這種分布式資料庫，完美相容mysql協議，可以扛住大併發，快取可以選用redis cluster需要做到高可用。
（4）分級管理：根據業務重要性進行分級管理，核心應用和服務優先使用更好的硬體，在服務部署上進行必要的隔離，避免故障的連鎖反應。低優先順序的服務通過啟動不同的執行緒或部署在不同的虛擬機器上進行隔離，而高優先順序的服務則需要部署在不同的物理機上。
（5）cdn快取： 資源常用資料快取cdn，一方面加快使用者訪問速度，另一方面減少後端伺服器負載壓力。
（7）預警機制：服務可用性，磁碟空間，cpu負載，記憶體使用率等指標需要有及時的告警機制。
（8）網路可用性：不用運營商，不同地域網路可達性監測
4.高可用設計建議：
健康碼服務是乙個典型的讀多寫少場景。以最簡易、常見的服務拓撲：客戶端 -> 閘道器 -> 主服務 ->快取&資料庫 -> 子服務，嘗試分析三高（高併發、高效能、高可用）設計的常見思路：
（1）服務、資料冗餘
資料冗餘：以關聯式資料庫為例，可以讀寫分離。極端故障可以進行主從切換實現故障恢復；考慮「西安一碼通」本身僅作為查詢介面，無錄入等操作，可嘗試clickhouse資料庫，該資料庫對於海量資料的查詢效能是很優秀的，基本上千萬級別查詢響應僅需百毫秒以內；但是也有問題，該資料庫對於更新操作不是很友好；可以在夜裡低峰做批量更新。
服務冗餘：包括接入網關、服務冗餘。在保障服務無狀態前提下，可以水平擴充套件服務提公升服務整體吞吐能力以及降低單節點（機房）故障的影響面，在分布式服務場景下需要關注服務分片、流量分片設計、服務註冊等單點問題；異地多活，可以搞多機房提高可用性。
（2）負載均衡：流控是保命手段，不是最優方案。「西安一碼通」是疫情防控的重中之重。建議增加算力，提高網路能力，優化負載均衡，確保外部流量能夠最優的分擔到後端伺服器處理。建議採用lvs+nginx+動態dns避免出現單點故障，如果不差錢可以採用f5等硬體負載；
（3）熱資料快取：避免頻繁向下游取資料導致下游、資料庫過載，同時提公升服務響應時間。當前場景下快取使用還需要額外關注資料一致性、快取可用性。
一致性方面：首選需要正確的**正規化保障，其次可以採用淘汰時間 + 非同步通知策略實現準實時一致性
可用性方面：類似redis cluster架構提供的分片 + 主從的分布式架構是很好的穩定性保障方案
（4）降級限流：針對服務鏈路各環節、節點需要評估流量閾值，針對過載流量及時限流保障服務最極端場景下的可用性。但是需要注意核心介面限流本身極大影響使用者體驗；對非核心功能，在過載期間可以考慮降級保障主服務可用。
（5）非同步化及快速失敗，非同步並行讀取需要的資訊，對積壓請求任務通過限制等待時間、甚至丟棄等快速失敗的方式也是提公升可用性的有效方式。
（6）dns負載均衡，多個ip對用同乙個網域名稱，最簡單是使用keepalived容災，使某台nginx不至於被打掛而影響整個集群。
（三）測試建議
新增高效能自動化測試，壓力測試；在發布前做預防機制；
服務演練：經常開展各種應急演練、災備演練工作，提高問題處理效率及驗證災備系統可用性。
以上是基於「西安一碼通」短時期故障的前、後端原因分析和解決措施建議，僅僅作為技術範疇的思考和**。
Redis 生成唯一碼的方式（一）
1 涉及到的表結構 create table int item identity id int 11 not null auto increment comment id name varchar 255 not null comment 名稱 alias varchar 255 not null ...
畢業小車出現的一些故障
1.上電後，除了電源指示燈亮，其他沒有工作 2.上電之後，指示燈亮，電機驅動沒有波形無反應 3.電機驅動正常工作後，小車兩個輪子行駛的方向不一致 4.調pid。解決方案 1a 測pa8引腳的pwm波是否正常，檢測結果無波形。不經過電源模組，直接給stm32 核心板供電，繼續測量pa8的pwm波，波形...
LINUX上執行docker出現一些的問題
1 檢查核心版本，必須是3.10及以上 命令 uname r 2 安裝docker 命令 yum install docker 3 啟動docker 命令 systemctl start docker 3.1 啟動docker報錯 如 job for docker.service failed be...