目前中小企業架構設計存在哪些問題?
# 1. 通病: 企業組織管理混亂
# 原因： 沒有完善的企業組織架構（分工和責任不明確）
# 2. 部門協同差勁
# 原因: 企業沒有規範的管理流程，部門之間溝通機會少，企業文化融合氛圍不濃等等造成的.
# 3. 組織效率低
# 原因: 多方協同出現了問題
1 . 戰略方向不明確，組織缺乏前瞻性
# 務實,務虛
# 初心: 解決這個社會的問題，解決某個行業的痛點，我希望來做的更好
# 使命,價值觀
# 拷克: 業績和價值觀五五開
2 . 部門職責不清晰,重置和空白
3 . 管理層級多，管理角色錯位
# 扁平化
# 事業部
# 阿米巴
4 . 企業內部體系不完整，責權不統一
權
責
利
5 . 部門協同差，組織效率低
中小企業IT系統架構面臨的問題
# 當業務發生變化，不斷的在原有系統上打補丁
# 當業務發展時，系統不斷出現瓶頸
# 卡頓，資料庫經常鎖死
# 使用者網站打不開，白屏
# 流量一上來就容易掛
技術團隊的現狀
# 技術團隊人數不超過50人
# 伺服器數量: 10-50臺
# 寬頻: 100M
中小企業從零開始目前專案開發現狀:
# 應用系統開發
# 前端開發: Vue.js,bootstrap
# SSM: SpringMVC,SpringBoot,MyBatis
# Tomcat
# 資料庫開發:
# Mysql: CRUD
# 測試:
# 開發人員自己測試
# 沒有壓測
# 不清楚系統的負載邊界.
# 線上部署:
# 應用伺服器和資料庫伺服器在同一臺伺服器上
# Linux環境沒裝過JDK,Mysql，如何引數配置和調優.
為什麼會出現這麼多問題？
# 企業沒有一個優秀的架構師
怎樣才能成為一名優秀的架構師
# 得有實戰經驗
# 實戰的應用場景
歷經15次架構演進過程
# 首先:
定義當前企業的架構，目前所處的一個階段並且繪製出架構圖譜
# 定位問題:
根據實際情況繪製新的架構圖譜(重構)
在看下面架構演變請先看以下基礎概念
基礎概念
分散式
系統中的多個模組在不同伺服器上部署，即可稱為分散式系 統，如Tomcat和資料庫分別部署在不同的伺服器上，或兩個相同功能的Tomcat分別部署在不同伺服器上
高可用
系統中部分節點失效時，其他節點能夠接替它繼續提供服務，則可認為系統具有高可用性。
叢集
一個特定領域的軟體部署在多臺伺服器上並作為一個整體提供一類服務，這個整體稱為叢集。
負載均衡
請求傳送到系統時，通過某些方式把請求均勻分發到多個節點上，使系統中每個節點能夠均勻的處理請求負載，則可認為系統是負載均衡的
正向代理和反向代理
系統內部要訪問外部網路時，統一通過一個代理伺服器把請求轉發出去，在外部網路看來就是代理伺服器發起的訪問，此時代理伺服器實現的是正向代理；當外部請求進入系統時，代理伺服器把該請求轉發到系統中的某臺伺服器上，對外部請求來說，與之互動的只有代理伺服器，此時代理伺服器實現的是反向代理。簡單來說，正向代理是代理伺服器代替系統內部來訪問外部網路的過程，反向代理是外部請求訪問系統時通過代理伺服器轉發到內部伺服器的過程. 可以看我squid和nginx的代理相關文章, 寫的不好歡迎留言,我看到會改正
以下架構調整參考來自淘寶
第一次架構: 單體架構
# Tomcat + 資料庫部署在同一臺伺服器上:
# 問題:
# 1. 隨著使用者增長，tomcat和資料庫之間相互競爭伺服器資源
# 2. 單機效能不足以支撐業務
# 3. 整個伺服器掛掉
第二次架構: Tomcat和資料庫分開部署
# Tomcat和資料庫分別獨佔伺服器資源，顯著提高兩者的效能
# 問題
# 1. 使用者增長: 讀寫都在同一個資料庫，壓力很大，資料庫就成了瓶頸
# 2. 第一步: 把應用伺服器和資料庫進行分表，獨立部署，Tomcat和資料庫伺服器記憶體擴大
# 資料量小的時候，匯出SQL，資料多，資料檔案的遷移.
第三次架構: 引入本地快取和分散式快取
# Tomcat伺服器上或同JVM增加本地快取
# 在外部增加分散式快取
# 快取熱資料和靜態html頁面
# 通過快取把大多數的請求在讀寫資料庫前攔截掉
# 會應用到那些技術棧尼?
# memcached 作為本地快取
# Redis作為分散式快取
# 問題.
# 快取一致性，快取穿透/擊穿，快取雪崩
# 熱點資料集中生效
# 快取抗住了大部分用於請求，使用者增長，併發的壓力就會落到tomcat上，響應很慢
第四次架構: 引入反向代理實現負載均衡
# 多臺伺服器上分別部署tomcat,使用Nging把請求分發到每一個tomcat中
# 假設:
# Tomcat最多支援100併發
# Nginx請求分發500個Tomcat，就能抗住50000個併發
# 問題:
# Session共享
# 檔案上傳下載問題
第五次架構: 資料庫讀寫分離
# 讀庫
# 寫庫
# MyCat等等資料庫中介軟體
# 問題:
# 資料同步，資料一致性問題
# 業務增長，不同業務之間訪問差距較大，相互競爭資料庫資源，影響效能
第六次架構: 資料庫按業務分庫
# 問題
# 使用者增長: 單機的寫庫會逐漸達到效能瓶頸
第七次架構: 將大表分成小表
# 問題:
# 資料庫和Tomcat能夠水平擴充套件，Nginx就會成為系統的瓶頸
第八次架構: 使用LVS或者F5使用多個Nginx負載均衡
# 問題:
# LVS單機
第九次架構: 通過DNS輪訓實現機房間的負載均衡
# 通過DNS伺服器輪訓或者其他策略
# 千萬級別到億級別，通過機房來解決
第十次架構: 引入NoSQL資料庫和搜尋引擎
# 對於全文檢索，可變資料結構，資料庫天生不適用
# 海量檔案儲存: HDFS
# Key Value型別的資料: HBase 和Redis
# 全文檢索: ElasticSearch
第十一次架構: 把大應用拆分為小應用
# 按照業務板塊來劃分應用程式碼
# 單個應用職責很清晰，相互之間做到獨立升級迭代
# 應用之間會涉及公共配置
# 分散式配置中心 ZooKeeper來解決
第十二次架構: 複用的功能抽離成微服務
第十三次架構: 引入企業服務匯流排遮蔽服務介面訪問的差異
第十四次架構: 引入容器化技術實現環境隔離和動態服務管理
# 目前最流行技術是Docker
# 容器管理: kubernetes
# 雙11來之前:
在現有的機器叢集上劃分出伺服器來啟動Docker容器，增強服務的效能
# 雙11之後:
活動結束後: 就可以關閉容器，對機器上的其他服務不會造成任何影響
第十五次架構: 以雲平臺承載系統
# 所有系統都部署在公有云上:
# 2019年雙十一天貓2684億，阿里巴巴所有核心繫統全部上雲.
# 系統可部署到公有云上,利用公有云的海量機器資源,解決動態硬體資源的問題,在大促的時間段裡,在雲平臺中臨時
# 申請更多的資源，結合Docker和k8s來快速部署服務,在大促結束後釋放資源，真正做到按需付費,資源利用率大大提高,
# 同時降低了運維成本.
# 所謂的雲平臺，就是把海量機器資源，通過統一的資源管理，抽象成一個資源整體，在之上可按需動態申請硬體資源(
# 如CPU，記憶體，網路等),並且之上提供通用的作業系統，提供常用的技術元件(比如Hadoop技術棧，MPP資料庫等)供使用者
# 使用,甚至提供開發好的應用，使用者不需要關心應用內部使用了什麼技術，就能解決需求(視屏轉碼服務，郵件服務，
# 個人部落格等)，在雲平臺中會涉及以下幾個概念.
# LaaS: 基礎設施即服務,對應上面所說的機器資源統一為資源整體，可動態申請硬體資源的層面:
# PaaS: 平臺即服務,對應上面所說提供常用的技術元件方便系統開發和維護,MaxComputer,Fink-Bink,Hadoop技術元件
# SaaS: 軟體即服務,對應上面所說的提供開發好的應用或服務,按功能和效能要求付費,比如:
#（行業解決方案視訊轉碼服務，郵件服務，個人部落格等）
# 於是各種雲平臺應運而生:
# 阿里雲
# 騰訊雲
# 七牛雲
# 青雲
架構設計
架構的調整是否必須按照上述進行架構?
以上所說的架構演變順序只是針對某個側面進行單獨的改進，在實際場景中，可能同一時間會有幾個問題需要解決，或者可能先達到瓶頸的是另外的方面，這時候就應該按照實際問題實際解決。如在政府類的併發量可能不大，但業務可能很豐富的場景，高併發就不是重點解決的問題，此時優先需要的可能會是豐富需求的解決方案。
對於將要實施的系統，架構應該設計到什麼程度?
對於單次實施並且效能指標明確的系統，架構設計到能夠支援系統的效能指標要求就足夠了，但要留有擴充套件架構的介面以便不備之需。對於不斷髮展的系統，如電商平臺，應設計到能滿足下一階段使用者量和效能指標要求的程度，並根據業務的增長不斷的迭代升級架構，以支援更高的併發和更豐富的業務
架構設計原則
# `N+1設計`
# 系統中的每個元件都應做到沒有單點故障；（HA）
# 回滾設計: 確保系統可以向前相容，在系統升級時應能有辦法回滾版本；
# 禁用設計: 應該提供控制具體功能是否可用的配置，在系統出現故障時能夠快速下線功能；
# 監控設計: 在設計階段就要考慮監控的手段；
# 多活資料中心設計: 若系統需要極高的高可用，應考慮在多地實施資料中心進行多活，至少在一個機房斷電的情況下系統依然可用；
# 採用成熟的技術: 剛開發的或開源的技術往往存在很多隱藏的bug，出了問題沒有商業支援可能會是一個災難；
# 資源隔離設計: 應避免單一業務佔用全部資源；
# 架構應能水平擴充套件。系統只有做到能水平擴充套件，才能有效避免瓶頸問題；
# 非核心則購買。非核心功能若需要佔用大量的研發資源才能解決，則考慮購買成熟的產品；
# 使用商用硬體。商用硬體能有效降低硬體故障的機率；
# 快速迭代。系統應該快速開發小功能模組，儘快上線進行驗證，早日發現問題大大降低系統交付的風險；
# 無狀態設計。服務介面應該做成無狀態的，當前介面的訪問不依賴於介面上次訪問的狀態。