MIX Fold3包裝盒泄露 新機本月登場
小米的全新折疊屏旗艦MIX Fold3將于本月發(fā)布，近日該機的真機包裝盒在網(wǎng)上泄露。從圖上來看，新的MIX Fold3包裝盒在外觀設(shè)計方面延續(xù)了之前的方案，變化不大，這也是目前小米旗艦
作為架構(gòu)師，工作內(nèi)容并非迷霧重重。一個經(jīng)驗豐富的架構(gòu)師必須對現(xiàn)有技術(shù)有深刻的了解，并且對已被實踐證明的架構(gòu)模式胸有成竹。基于對業(yè)務(wù)需求的深入理解，他們會選擇并組合恰當(dāng)?shù)募軜?gòu)模式，進而對這些方案進行必要的修改和優(yōu)化。
盡管軟件技術(shù)經(jīng)歷了幾十年的發(fā)展，并且持續(xù)涌現(xiàn)新技術(shù)，成熟的技術(shù)仍占主導(dǎo)，因為這些技術(shù)已被眾多應(yīng)用場景所驗證。例如，涉及高可用性的主備方案、集群技術(shù)，高性能的負(fù)載均衡、多路復(fù)用技術(shù)，以及可擴展的分層和插件化技術(shù)等，這些都是在明確目標(biāo)后可以迅速找到的解決方案。
通常情況下，只有當(dāng)現(xiàn)有方案無法滿足特定需求時，我們才考慮創(chuàng)新。然而，這些創(chuàng)新大多仍然建立在成熟的技術(shù)之上。
例如，NoSQL 中的 Key-Value 存儲與數(shù)據(jù)庫索引本質(zhì)上相似，而 Memcache 實際上是將數(shù)據(jù)庫索引轉(zhuǎn)變成獨立的緩存系統(tǒng)。
Hadoop 的大文件存儲解決方案，基于的是集群和數(shù)據(jù)復(fù)制的技術(shù)。
Docker 的虛擬化技術(shù)是建立在 Linux 容器（LXC）之上的。
同樣，LevelDB 使用的文件存儲結(jié)構(gòu)是跳表（Skip List）。
在《技術(shù)的本質(zhì)》一書中，對技術(shù)的組合有清晰的闡述：新技術(shù)都是在現(xiàn)有技術(shù)的基礎(chǔ)上發(fā)展起來的，現(xiàn)有技術(shù)又來源于先前的技術(shù)。將技術(shù)進行功能性分組，可以大大簡化設(shè)計過程，這是技術(shù)“模塊化”的首要原因。技術(shù)的“組合”和“遞歸”特征，將徹底改變我們對技術(shù)本質(zhì)的認(rèn)識。
盡管在很多情況下，通過組合和調(diào)整現(xiàn)有的技術(shù)或架構(gòu)模式，我們可以得到所需的解決方案，但這并不意味著架構(gòu)設(shè)計是一項簡單的工作。由于可供選擇的模式眾多，可能的組合方案更是數(shù)不勝數(shù)，常常導(dǎo)致同一個問題可能有多種解決方案。如果在這些組合方案中加入創(chuàng)新元素，可選的解決方案則會增加更多。因此，設(shè)計最終的方案并不是一件容易的事，這一階段也常是許多架構(gòu)師易于出錯的環(huán)節(jié)。
首先，一個常見的錯誤是追求設(shè)計出最完美的架構(gòu)。許多架構(gòu)師在設(shè)計時常常懷有一種技術(shù)情結(jié)，認(rèn)為只有設(shè)計出一流的架構(gòu)才能展示他們的技術(shù)水平。例如，在設(shè)計高可用性方案時，他們可能會偏好使用集群方案而不是主備方案，因為前者更加優(yōu)越和強大；在高性能方案中，可能會傾向于使用業(yè)界領(lǐng)先的技術(shù)如淘寶的某種方案。
然而，根據(jù)“適用原則”和“簡單原則”，選擇適合自己業(yè)務(wù)、團隊和技術(shù)能力的方案才是更為理智的選擇。否則，可能會造成資源的浪費，如開發(fā)了遠(yuǎn)超實際需要的系統(tǒng)，或者設(shè)計出的系統(tǒng)根本無法由現(xiàn)有團隊實現(xiàn)。
第二個常見錯誤是只制定一個方案。許多架構(gòu)師可能會在心中簡單比較幾個方案，然后選擇一個看似最佳的方案進行深入設(shè)計。這種做法存在多個缺點：評估可能過于膚淺，沒有全面考慮，或是由于某個方案的一個缺點就草率地否決了它，而忽略了這可能是綜合最優(yōu)的選擇。架構(gòu)師的經(jīng)驗和知識是有限的，有時候他們的評估標(biāo)準(zhǔn)可能已過時或不適用于新情況，或者某些評估標(biāo)準(zhǔn)本身就是錯誤的。
因此，架構(gòu)師應(yīng)該設(shè)計多個備選方案，理想的方案數(shù)量是三到五個。少于三個可能由于思考不夠全面，多于五個則可能花費過多時間和精力，且方案間的差異可能不明顯。備選方案應(yīng)具有較大的差異性，如主備和集群方案的區(qū)別，或者不同技術(shù)實現(xiàn)主備的差異明顯，如使用ZooKeeper與使用Keepalived。
最后，第三個錯誤是備選方案過于詳細(xì)。一些架構(gòu)師可能會將備選方案寫得非常詳細(xì)，這不僅消耗大量時間和精力，還可能使人過于關(guān)注細(xì)節(jié)而忽視整體設(shè)計，從而導(dǎo)致備選方案數(shù)量不足或差異不大。正確的方法是在備選階段關(guān)注技術(shù)選型的顯著差異，而不是深入到技術(shù)細(xì)節(jié)。例如，使用ZooKeeper與Keepalived來實現(xiàn)主備就是一個較大的技術(shù)差異，而在使用相同技術(shù)的方案中進行細(xì)節(jié)上的區(qū)分，如節(jié)點設(shè)計的微小變化，這樣的區(qū)分在備選階段并不必要，具體的節(jié)點設(shè)計可以在最終方案中決定。
方案：
圖片
方案概述如下：
備選方案 3：自主研發(fā)存儲系統(tǒng)的集群方案
在備選方案 2 的基礎(chǔ)上，我們考慮替換 MySQL 存儲，因為關(guān)系型數(shù)據(jù)庫的特性并不完全符合消息隊列的數(shù)據(jù)處理需求。借鑒 Kafka 的設(shè)計思路，可以自行開發(fā)一套專門的文件存儲和復(fù)制系統(tǒng)（具體方案細(xì)節(jié)將在實際設(shè)計階段詳細(xì)闡述）。
從高性能消息讀取的單機系統(tǒng)設(shè)計來看，由于團隊主要使用 Java，備選方案 2 和 3 均采用了基于 Netty 的高性能網(wǎng)絡(luò)庫。這反映了團隊的技術(shù)背景對選擇范圍的影響。一般而言，成熟的團隊不易頻繁更換技術(shù)棧，而新成立的團隊則更可能嘗試新技術(shù)。
以上簡要介紹了三種備選方案以示范設(shè)計流程，實際應(yīng)用中方案會更為復(fù)雜。架構(gòu)師的技術(shù)儲備和經(jīng)驗越豐富，能夠提供的備選方案就越多，這有助于更有效地制定設(shè)計方案。例如，在開源方案中不僅可以選擇 Kafka，還可以考慮 ActiveMQ、RabbitMQ 等；在考慮集群的存儲方案時，除了 MySQL，還可以考慮使用 HBase 或?qū)?Redis 與 MySQL 結(jié)合使用；自研的文件系統(tǒng)也可以參考 Kafka、LevelDB 或 HBase 等多種模型。這里由于篇幅限制，不再詳細(xì)展開。
本文鏈接：http://m.www897cc.com/showinfo-26-84026-0.html聊聊架構(gòu)設(shè)計流程：設(shè)計備選方案
聲明：本網(wǎng)頁內(nèi)容旨在傳播知識，若有侵權(quán)等問題請及時與本網(wǎng)聯(lián)系，我們將在第一時間刪除處理。郵件：2376512515@qq.com
Copyright ? 2016-2023 天津谷騏科技有限公司 版權(quán)所有 sitemap.xml
違法及侵權(quán)請聯(lián)系：2376512515@qq.com 津ICP備18001702號
津公網(wǎng)安備 12010102000574號