資訊專欄INFORMATION COLUMN
什么時候需要使用架構原則?
1：架構設計
2：項目驗收
總結：諸事不決，架構原則
架構設計原則
1：體系安全
2：成本合理
3：穩(wěn)定可靠
4：性能適用
5：運維高效
體系安全
1：根據(jù)系統(tǒng)的合規(guī)標準設定目標
1.1：合規(guī)標準：1,國際標準;2,國家標準;3,行業(yè)標準;4,公司要求
2：成體系地規(guī)劃系統(tǒng)的整體安全
3：在所有層次實現(xiàn)安全性
4：風險評估并準備應對預案
成本合理
1：持續(xù)觀察評估
1.1 我們應該爭取每年都做到一次費用的降低
2：使用托管服務
2.1 托管服務如：云數(shù)據(jù)庫等等paas產品，雖然看起來單價很貴，但是包含的價值很多。
3：臨時資源
3.1搭建函數(shù)計算等，調用即收費等資源
4：多層次優(yōu)化成本
4.1 從整理架構設計，購買方案來達到成本優(yōu)化的目的
總結：我們的架構不但能工作，最好能不花錢
架構可靠
1：根據(jù)業(yè)務需要設定可靠性指標
2：為了失敗做設計才能保持不敗
3：避免單點故障
4：在架構中實現(xiàn)松耦合
5：預測故障形式并準備應對預案
總結：所有東西都會壞，壞了這個架構也能自己恢復
性能適用
1：根據(jù)業(yè)務需要確定性能指標
2：了解先進技術并合理選擇
3：尋找數(shù)據(jù)特點和熱度，設計緩存
4：系統(tǒng)實現(xiàn)彈性
總結：性能不用極致，超過需求一點點就好
運維高效
1：做好監(jiān)控對系統(tǒng)了如指掌
1.1 一定要用好云上的監(jiān)控
2：自動化減少人工的風險
3：更新或是替換跳出舊思想束縛
4：減少底層維護聚焦應用層維護
4.1 可以的話，使用容器，微服務架構
總結：好的架構，應該可以實現(xiàn)，并容易維護
如何做到服務器安全?
1：數(shù)據(jù)靜態(tài)安全
使用云硬盤的數(shù)據(jù)盤加密，本地硬盤可以操作系統(tǒng)內加密
2：數(shù)據(jù)動態(tài)安全
https數(shù)據(jù)傳遞
3：網(wǎng)絡安全
3.1 VPC控制網(wǎng)絡安全
3.2 控制本機打開的端口;啟用本機操作系統(tǒng)防火墻
3.2.1 只放行需要的提供業(yè)務的端口，其它端口關閉。啟動系統(tǒng)防火墻
3.3 使用主機安全服務，DDOS攻擊保護，架構保護
3.4 訪問控制：
密碼訪問(不推薦);
密鑰對訪問(推薦);
或者在服務器環(huán)境部署完成之后，關閉服務器遠程登錄
3.5 審計和跟蹤
使用日志服務收集日志
應用程序內的日志管理
3.6 事件響應
主機恢復流程設計和應對練習
如何優(yōu)化服務器成本?
1：選擇合適主機類型
2：不用就關機
關機可以釋放CPU,內存資源
3：靈活組合購買方案
綜合考慮：按需計費，包年包月，競價實例
4：費用由主機運行時間，流量費組成
4.1 流量費，流入免費，私網(wǎng)流出到同區(qū)域免費
4.2 平衡流量和算力之間的關系
如何確保服務器可靠性?
1：云服務器是單點，需要假設會損壞做設計
2：選擇云服務器組的反親和性，避免接近部署
3：需要集群化分布式安排服務器
如何確保服務器性能?
1：使用監(jiān)控
2：性能與應用特性
3：AZ內和跨AZ的網(wǎng)絡延遲不同
4：EVS的性能選擇
EVS的IOPS和帶寬較難同時達到
5：很多時候服務器在等待數(shù)據(jù)
服務器可維護性考慮
1：用戶需要維護云服務器
2：操作系統(tǒng)補丁
3：應用軟件升級
4：自建應用程序升級
5：數(shù)據(jù)備份，主機備份
6：其它安全的維護
如何去檢查架構是不是符合架構設計原則?--安全
1：我們在架構上每一層的網(wǎng)絡安全設計是什么樣的
2：整個體系的身份認證和權限邊界是什么樣的
3：運行中如何檢查和評估安全風險
4：如何保護計算資源，防止被侵占
5：數(shù)據(jù)如何分級，各級別的安全設置，能否自動化定級?生命周期規(guī)則?
5.1 不同級別的數(shù)據(jù)在靜態(tài)如何保護
5.2 不同級別的數(shù)據(jù)在傳輸中如何保護
6：當安全事件發(fā)生時，如何探測，響應從而恢復?
如何去檢查架構是不是符合架構設計原則?--成本
1：我們是不是使用了托管服務而不是自建組件?
2：我們是如何去管理我們的資源使用的?
2.1 如何講成本歸攏到產品線，成本中心等負責實體上?
2.2 我們如何管控資源的使用原因，時長和最后的開銷?
2.3 我們如何管理資源生命周期，從而及時關閉終期資源?
3：在組件服務選擇的時候，我們有沒有去評估成本?
4：我們是如何評估，計算來決策計算模式選擇的?
5：資源的使用重心是在哪里?如何去針對重點開銷做優(yōu)化?
如何去檢查架構是不是符合架構設計原則?--可靠性
1：服務限額和其它限制是如何管理的?
2：網(wǎng)絡拓撲是如何規(guī)劃的，如果鏈路損失如何響應
3：是否需要設計一個分布式系統(tǒng)防止組件損壞
4：如何進行變更?如何確保定期變更及時被執(zhí)行
5：根據(jù)不同的數(shù)據(jù)分級，如何備份和恢復這些數(shù)據(jù)
數(shù)據(jù)可靠性指標如何
備份恢復的測試
6：容災的規(guī)劃是什么樣的?如何測試可靠性?
如何去檢查架構是不是符合架構設計原則?--性能
1：我們定義了各個模塊需要的性能指標了嗎?
2：我們已經選擇了最優(yōu)的組件了嗎?
我們選對了計算實例的類型了嗎?
我們選對了存儲方案和存儲配置了嗎?
我們選對了數(shù)據(jù)庫方案了嗎?
我們是不是使用了托管服務而不是自建組件?
我們考慮過新型的服務組件了嗎?
3：我們的組件已經按期待的性能在工作了嗎?
如何去檢查架構是不是符合架構設計原則?--運維
1：我們如何感知應用程序在運行時候的狀態(tài)指標
2：我們如何降低部署這個架構時候的風險
3：我們是否知道這個應用環(huán)境是否在健康工作
4：我們需要做那些維護工作?何時進行維護?有沒有記錄?如何降低維護操作異常的風險?維護對業(yè)務持續(xù)性有何影響?
5：我們需要安排那些運維流程來管理對資源的使用?
文章版權歸作者所有，未經允許請勿轉載,若此文章存在違規(guī)行為，您可以聯(lián)系管理員刪除。
轉載請注明本文地址：http://specialneedsforspecialkids.com/yun/127942.html
摘要：阿里巴巴的共享服務理念以及企業(yè)級互聯(lián)網(wǎng)架構建設的思路，給這些企業(yè)帶來了不少新的思路，這也是我最終決定寫這本書的最主要原因。盡在雙阿里巴巴技術演進與超越是迄今唯一由阿里巴巴集團官方出品全面闡述雙八年以來在技術和商業(yè)上演進和創(chuàng)新歷程的書籍。 showImg(https://segmentfault.com/img/remote/1460000015386860); 1、大型網(wǎng)站技術架構：核...
摘要：由于文章內容較長，所以我把它分成兩篇小文章，在第一篇優(yōu)秀架構師必須掌握的架構思維中，我會先介紹抽象分層分治和演化這四種應對復雜性的基本思維。另外，上面的算法是兩路歸并，也可以采用多路歸并，甚至是采用堆排序進行優(yōu)化，但是總體分治思路沒有變化。 showImg(https://segmentfault.com/img/bVbeYpP?w=642&h=400); 介紹 架構的本質是管理復雜性...
摘要：由于文章內容較長，所以我把它分成兩篇小文章，在第一篇優(yōu)秀架構師必須掌握的架構思維中，我會先介紹抽象分層分治和演化這四種應對復雜性的基本思維。另外，上面的算法是兩路歸并，也可以采用多路歸并，甚至是采用堆排序進行優(yōu)化，但是總體分治思路沒有變化。 showImg(https://segmentfault.com/img/bVbeYpP?w=642&h=400); 介紹 架構的本質是管理復雜性...
摘要：本篇文章來自于騰訊和共同舉辦的技術開放日后臺專場出品人傅鴻城的分享，由壹佰案例整理編輯。對于騰訊而言，后臺服務可用性都是四個九，四個九轉化為時間就要求一年內的故障時間不能超過分鐘。 showImg(https://segmentfault.com/img/bVvL5f); 本篇文章來自于騰訊SNG和msup共同舉辦的技術開放日后臺專場出品人傅鴻城的分享，由壹佰案例整理編輯。原文發(fā)布在壹...
閱讀 284·2024-11-07 18:25
閱讀 130363·2024-02-01 10:43
閱讀 868·2024-01-31 14:58
閱讀 828·2024-01-31 14:54
閱讀 82766·2024-01-29 17:11
閱讀 3047·2024-01-25 14:55
閱讀 1985·2023-06-02 13:36
閱讀 3033·2023-05-23 10:26
