生在中國這片熱土，我們做程序開發(fā)的人要面臨很多的挑戰(zhàn)。只要生命不息，挑戰(zhàn)就永遠不會停止。

比如最近瘋傳的 35 歲程序員送外賣。這明顯點出了在中國搞開發(fā)，要面臨的其中之一挑戰(zhàn)：年齡。

[[276666]]

在整個 IT 領(lǐng)域，大多數(shù)的開發(fā)者都屬于普通人。只有極少數(shù)部分人能站在技術(shù)的尖端引領(lǐng)技術(shù)的前進與走向。那么，普通的開發(fā)者，又很容易被新人替換。新人更經(jīng)濟實惠，壓力小。而老開發(fā)人員技術(shù)的天花板無法打破的情況下。要面臨跟著一群小朋友一起起早貪黑的工作模式。甚至于會出現(xiàn)自己一把年紀，上面的領(lǐng)導比自己還小好多歲的窘境。

肯定有人會說我們這群老人矯情。但是，又有幾人能做到內(nèi)心毫無波瀾呢?

本篇博文主要是針對我們這群普通的開發(fā)者處境所寫。請允許我在這里販賣焦慮。

一、系統(tǒng)架構(gòu)

作為技術(shù)這條路線，最終都會偏架構(gòu)方向。即使做技術(shù)經(jīng)理或總監(jiān)。都必須對系統(tǒng)架構(gòu)要有一定的知識儲備，以備對團隊的架構(gòu)搭建與變更做出準確的判斷。

這里并不是說我們?nèi)ピO(shè)計一些千萬級別以上 PV 的系統(tǒng)架構(gòu)。做為普通的開發(fā)者，要接觸上億的系統(tǒng)平臺相對來說機會并不是很多。即使接觸了，也僅僅只是這個平臺里面的一個小螺絲。要能主導這個架構(gòu)的設(shè)計，還稍顯稚嫩。我再次說明一下，這里僅僅只對普通的開發(fā)者。不指那些尖端的高技術(shù)人才。

在我的理念當中，千萬級別及以下 PV 的構(gòu)架，通常用不到微服務。所以，不要用微服務來坑自己。加重架構(gòu)的復雜度。

在這個體系里面有以下技術(shù)/服務/文檔可能是我們要涉及的：

• 隊列服務：Redis、Kafka、RabbitMQ 等消息服務中間件。
• 緩存服務：Redis、Memcache。這里不太推薦 Memcache。
• 多進程/多線程：用來異步處理一些 CPU 數(shù)據(jù)密集計算的任務或異步處理推送、短信等任務。
• 負載均衡服務：可以采用阿里云成熟的負載均衡服務 SLB 服務。
• 日志存儲與分析服務：常聽到 ELK 就屬于一組組合。不過，我推薦使用阿里云的日志服務。集成了報警功能。這個非常實用。
• 文件存儲服務：系統(tǒng)上傳的文件不能與業(yè)務服務器存放一起。會影響業(yè)務服務器的帶寬。導致業(yè)務訪問的數(shù)據(jù)交互延遲與超時。可以采用阿里云的 OSS。一般千萬級別自建這樣的存儲系統(tǒng)服務，從成本上來說根本不劃算。
• CDN 服務：即使我們用了獨立的文件夾服務器存儲文件。但是，在訪問的時候由于用戶所處網(wǎng)絡(luò)不同(電信、移動、聯(lián)通)，以及區(qū)域不同(南方/北方)。所以，CDN 會加快用戶訪問文件的速度。提升用戶體驗。
• 數(shù)據(jù)庫：一主多從構(gòu)架。具體要多少個從數(shù)據(jù)庫根據(jù)自己的業(yè)務量來設(shè)計。通常中小型平臺使用阿里云的 RDS 比自建數(shù)據(jù)庫服務更加劃算。否則，團隊會配備專業(yè)的 DBA 來維護數(shù)據(jù)庫服務器。推薦使用阿里云的 RDS 服務。對了。這里說的是MySQL 數(shù)據(jù)庫。其他忽略。
• 監(jiān)控系統(tǒng)：現(xiàn)如今像阿里云這樣的平臺，都提供了監(jiān)控服務。像服務器 CPU、內(nèi)存使用率告警。數(shù)據(jù)庫資源報警。自建的話，不僅維護需要專人，還可能會導致監(jiān)控不完善造成的損失。千萬 PV 級別不推薦。
• 專用網(wǎng)絡(luò) VPC：這個說的是阿里云的 VPC 服務。當然，其他云平臺也有。它的核心功能是給自己所有的服務器虛擬一個網(wǎng)絡(luò)進行管理。避免直接被外網(wǎng)訪問，或直接訪問外網(wǎng)。說得再直接一點就是避免風險。

像我這樣普通的大齡開發(fā)者，經(jīng)歷過的大大小小項目也挺多的。要真的能達到千萬級別 PV 的挺少的。通常要面臨的挑戰(zhàn)如下：

QPS：即每秒請求量。通常我們服務器能支持 2000 + 即可。除非做搶購等這種秒殺型的活動，否則很多的 Web 業(yè)務根本用不到 2000+。

海量數(shù)據(jù)：很多時候制約性能的數(shù)據(jù)庫。對海量數(shù)據(jù)存儲就顯示很重要。比如，訂單分庫分表解決。分表解決單表查詢性能、分為解決單庫性能。

二、網(wǎng)站劫持

網(wǎng)站劫持這是一個比較籠統(tǒng)的叫法。實際有如下幾種劫持：

• URL 跳轉(zhuǎn)型劫持：輸入 A 域名，強制跳轉(zhuǎn)至 B 域名。
• 注入型劫持。
• DNS 劫持。

而注入型劫持，又分以下幾種：

1. 注入 JS 類劫持：在正常頁面注入 JS 代碼實現(xiàn)劫持。常見的就是運營商強制注入廣告 JS。
2. iframe 類劫持：將正常頁面嵌入iframe或者頁面增加iframe頁面。
3. 篡改頁面類劫持：正常頁面出現(xiàn)多余的劫持網(wǎng)頁標簽，導致頁面整體大小發(fā)生變化。
4. DNS 劫持：

• 在工作中，經(jīng)常會有用戶跟我們的客服同事反饋 App 打不開或報錯。這其中有一部分就是 DNS 被劫持所致。劫持之后 App 請求接口拿不到數(shù)據(jù)或拿不到指定的數(shù)據(jù)，肯定會報錯。影響用戶正常的訪問。
• URL 跳轉(zhuǎn)型劫持與注入型劫持都可以通過 HTTPS 方式解決。而 DNS 劫持就比較特殊了。
• 關(guān)于 DNS 劫持解決的辦法是通過直接訪問受信任的 DNS 來解決。因為，這種 DNS 的劫持通常是運營商 Local DNS 緩存問題造成的。比如，攻擊者污染了根 DNS 服務器。導致運營商同步造成了數(shù)據(jù)的污染。自然訪問就會出現(xiàn)問題。

所幸，我們可以采用類似阿里云這種平臺提供的 HTTPDNS 服務。來解決 DNS 劫持的問題。

HTTPDNS 的功能特性：

• 防劫持:繞過運營商Local DNS，避免域名劫持，讓每一次訪問都暢通無阻。
• 精準調(diào)度:基于訪問的來源IP，獲得最精準的解析結(jié)果，讓客戶端就近接入業(yè)務節(jié)點。
• 0ms解析延遲:通過熱點域名預解析、緩存DNS解析結(jié)果、解析結(jié)果懶更新策略等方式實現(xiàn)0解析延遲。
• 快速生效:避免Local DNS不遵循權(quán)威TTL，解析結(jié)果長時間無法更新的問題。
• 降低解析失敗率:有效降低無線場景下解析失敗的比率。
• 穩(wěn)定可靠:99.9%的可用性，確保域名解析服務穩(wěn)定可靠。

三、系統(tǒng)安全

系統(tǒng)安全真的真的特別重要。作為一名開發(fā)老兵，心中始終要有一根弦：代碼千萬行，安全第一條。

常見安全防范：

• 網(wǎng)絡(luò)安全：通過專用網(wǎng)絡(luò) VPC 把所有的業(yè)務服務器進行網(wǎng)絡(luò)隔離，再采購堡壘機進行服務器管理。
• 密碼強度：管理員賬號一定要采用 大小寫混合且包含數(shù)字的 20 位及以上的長度。業(yè)務系統(tǒng)用戶密碼不能為純數(shù)字且長度必須大于8位。同時也要避免連續(xù)相同的密碼。比如：AAAAAAAA。
• 密碼定期更換：不管密碼保存得再完美，總會遺漏導致信息泄漏。而定期更換能及時發(fā)現(xiàn)并堵住這些漏洞。推薦每 3 個月更換一次。
• SQL 防注入：現(xiàn)在基本上成熟的語言都有一套完整的防注入機制。比如 PHP 語言的 PDO 擴展提供的預處理機制(當然數(shù)據(jù)庫必須支持預處理)。
• XSS(跨站腳本攻擊)：XSS 能截獲用戶的私密網(wǎng)頁內(nèi)容、Cookie 數(shù)據(jù)。通常是 JavaScript 腳本造成。最好的辦法是轉(zhuǎn)文存儲。
• CSRF(跨站請求偽造)：危害極大。所有敏感數(shù)據(jù)的讀寫操作采用 POST 限制。并且不允許跨域請求。在信息提交時，再做一次令牌的認證限制。
• 文件上傳漏洞：主要是避免用戶上傳惡意的腳本代碼獲得看我們的權(quán)限。解決辦法是就嚴格限制上傳文件的后綴。同時把上傳的文件放到專業(yè)的文件服務器。比如，放到阿里云提供的 OSS 服務器上。

四、代碼規(guī)范

即使你是外包或建站類型的項目開發(fā)，代碼規(guī)范能幫助你減少項目交叉維護帶來的痛苦。

不管是后端 PHP、Java、Go，還是 Web 前端，還是 Android/iOS 客戶端。必須有一套代碼規(guī)范。

PHP 目前通用的代碼規(guī)范：PSR。

Java 代碼規(guī)范：目前大多數(shù)都會遵循阿里開源出來的一套開發(fā)規(guī)范。搜索關(guān)鍵詞：阿里官方Java代碼規(guī)范標準。

Go：本身自己都代了一套代碼規(guī)范。直接遵循語言的規(guī)范即可。

Web 前端代碼規(guī)范：目前網(wǎng)上很多關(guān)于這個規(guī)范的整理。參照一套即可。

其實代碼規(guī)范這個東西是一種約定俗成的規(guī)定。并不是一層不變的教條。也要因地制宜的形式進行使用。不能生搬硬套。小團隊只要大體上沒有問題即可。大團隊可能就需要專門 Review 代碼的機制，以及代碼提交的輔助性插件來進行代碼規(guī)范的驗證。

五、工作匯報

如果你是老板可能就不需要進行工作向上匯報。否則，不管是哪個階層，工作匯報必須是工作中重要的一環(huán)。而每個層次的員工匯報工作的方式又有不同的側(cè)重點。

這里指的是工作匯報，而不是項目進度匯報。

(1)非核心開發(fā)員工

此類員工工作匯報應該有如下幾點：

• 具體做了哪些工作。完成百分比。如：登錄注冊功能開發(fā)。已用時 3 天。進度 80%。
• 遇到哪些問題。工作中遇到了哪些技術(shù)難題，自己是否能搞定，如果沒搞定是否請求過核心開發(fā)或組長級別協(xié)助。
• 后續(xù)工作計劃。這個是讓組長以及部門管理者知道接下來應該給你安排什么任務。

(2)核心開發(fā)員工

此類員工作為核心輸出。與非核心開發(fā)員工還是有區(qū)別的：

具體完成了哪些工作。

工作遇到的問題。

協(xié)助非核心開發(fā)做了哪些工作。

后續(xù)工作計劃。

核心員工重點工作是編寫核心業(yè)務代碼。并且指導并協(xié)助非核心開發(fā)員工遇到的各種難題。必要的時候，還需要對這此處于最底層梯隊的員工進行技術(shù)培訓。讓他們快速成長，慢慢成長為核心員工。

其次，核心員工不但能發(fā)現(xiàn)問題，還能解決問題。當需要部門管理者作決策時，是帶著A/B決策方案去。

(3)主管級別員工

這一類員工實則是與核心開發(fā)員工差不多。在核心開發(fā)員工上面進行一層工作的協(xié)調(diào)分配的工作。

六、職責清晰

這一點是針對開發(fā)轉(zhuǎn)技術(shù)管理路線的人而言。要讓每個開發(fā)準確知道自己所負責的事情。說穿了就是職責與責任。

如果職責不清晰，對一些事不關(guān)已高高掛起心態(tài)的人來說，會導致事情變得難以推進。只有明確職責之后，在事情沒有辦好的時候，就知道是誰的責任。

七、績效考核

這個與第六點相呼應。唯一的難點是要能及時且準確對責任做出評估，該扣績效扣績效。這獎勵的就獎勵。絕不能拖泥帶水、瞻前顧后。特別是拒絕過分護短的情況發(fā)生。

八、上下關(guān)系

很多剛從開發(fā)轉(zhuǎn)管理的人會有一個毛病。覺得要以技術(shù)實力去讓人服從。這明顯是不合適的。技術(shù)能力固然很重要，但不能本末倒置。天下技術(shù)千千萬。要以這種思維去做技術(shù)管理。那我相信，這世界上沒有幾人能坐得穩(wěn)。

所以，技術(shù)這東西得多去關(guān)注理論的東西即要。這樣才關(guān)鍵時刻能做出正確的選擇。

有些人還覺得要跟下面的人打成一片才能讓別人服從自己的工作安排。我并不這樣認為。工作中率先不服從或意見最多的反而是那些平常你極力去討好的人。我們在做管理的時候，只需要秉承公平公正公開的原則，去對待每一個人和工作即可。

那些不愿意服從的人，不管是交好的或關(guān)系遠的，都應該及時進行制止和批評。如果依然如此，那是他個人問題，不是我們管理的問題。除非我們的工作安排確實出現(xiàn)了嚴重的不公平不合理的情況。

以上都是自己瞎逼逼的一些總結(jié)。

管理這份活兒，它并不容易干。但好在能在此間修休汲取一些實戰(zhàn)經(jīng)驗來檢驗自己的不足。也是有幸之事兒了。