從2.0上線，一夜之間湧入20w+使用者，對於我們這種經常看不到併發的應用，壓力隨之而來，在緊急情況下，使用了最為暴力的擴容方案，堆機器，當機器堆到近20台時，使用者反饋卡頓降低了。但是隨之而來的另乙個問題又出現了，因為某乙個模組對資料操作的頻繁程度太高，大約每乙個使用者每秒插入5條記錄（本身這一模組的設計並不合理），不一會，資料庫cpu又增加到了99%。同樣是緊急情況下，在乙個緊急會議的召開下，決定先把該模組停掉，就這樣，在苦逼的人肉運維和連續三天的活動得以進行了下去。
經過這次活動，我們一致認為要對整個專案進行一次徹底的重構，原因有以下：
單純的增加機器擴容，無法應對未來的流量高峰，而且成本相對較高。
單資料庫在流量高峰並不是十分可靠，一旦資料庫掛了，相當於整個系統掛了。
還清之前的技術債，應用從1.0~2.0迭代的過程中，由於規範制定的不嚴謹，以及對設計模式理解的不深入,導致原來系統的業務耦合性很差，迭代新的業務基本上是牽一發動全身。
基於領域驅動對服務進行拆分，每個服務各司其職，即使其中乙個服務掛了，其他服務也能支撐整個系統執行，況且對每個服務進行配置集群，還可以達到高可用。
流量高峰到來時，能有效的進行分流，並且能針對併發量大的服務進行進一步的擴容。
資料庫進行拆庫，既不會因為某一項業務拖垮整個資料庫，相當於對資料庫流量進行了分流，不會說因為某一項業務而拖垮整個資料庫，造成更大損失。
服務拆分成多個，原來要部署乙個，現在部署多個，運維成本增加
服務之間相互呼叫，通訊勢必會有網路通訊的開銷。
資料庫被拆分為多個，事務無法保證。
服務被拆分成多個，如果減少運維成本，首先需要有一套ci/cd方案，現階段只是jenkins持續整合、持續發布，微服務如果搭配docker+k8s應該更合適。
現階段的rpc框架，對dubbo有過深入研究，底層是netty，是io多路復用模型，後續再展開**一下。總之能滿足現在服務之間的呼叫問題。
對於事務問題，就是現在的分布式事務解決方案了，由於業務的原因，我們採用了基於base理論的最終一致性解決方案。當然還有很多強一致性的，後續再展開討論
專案中錯誤型別的定義和思考
現在開發業務都是微服務，api呼叫rpc，rpc之間互相呼叫。除了常規的鏈結失敗或超時以外，還有很多業務上的錯誤。為了使返回的錯誤碼容易判斷和查錯，通常會靠乙個統一定義的錯誤 對映表。其實我們平時http的各種錯誤碼也就是乙個對映表。有一種做法是 裡寫死乙個對映表檔案，每次有新增去修改這個檔案。但是...
BI專案中ETL設計與思考
etl即資料抽取 extract 轉換 transform 裝載 load 的過程，它是構建資料倉儲的重要環節。etl是將業務系統的資料經過抽取 清洗轉換之後載入到資料倉儲的過程，目的是將企業中的分散 零亂 標準不統一的資料整合到一起，為企業的決策提供分析依據。etl是bi專案重要的乙個環節。通常情...
BI專案中ETL設計與思考
etl是將業務系統的資料經過抽取 清洗轉換之後載入到資料倉儲的過程，目的是將企業中的分散 零亂 標準不統一的資料整合到一起，為企業的決策提供分析依據。etl是bi專案重要的乙個環節。通常情況下，在bi專案中etl會花掉整個專案的1 3的時間,etl設計的好壞直接關接到bi專案的成敗。etl的設計分三...