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

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

[[276666]]

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

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

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

一、系統架構

作為技術這條路線，最終都會偏架構方向。即使做技術經理或總監。都必須對系統架構要有一定的知識儲備，以備對團隊的架構搭建與變更做出準確的判斷。

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

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

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

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

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

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

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

二、網站劫持

網站劫持這是一個比較籠統的叫法。實際有如下幾種劫持：

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

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

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

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

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

HTTPDNS 的功能特性：

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

三、系統安全

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

常見安全防范：

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

四、代碼規范

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

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

PHP 目前通用的代碼規范：PSR。

Java 代碼規范：目前大多數都會遵循阿里開源出來的一套開發規范。搜索關鍵詞：阿里官方Java代碼規范標準。

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

Web 前端代碼規范：目前網上很多關于這個規范的整理。參照一套即可。

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

五、工作匯報

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

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

(1)非核心開發員工

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

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

(2)核心開發員工

此類員工作為核心輸出。與非核心開發員工還是有區別的：

具體完成了哪些工作。

工作遇到的問題。

協助非核心開發做了哪些工作。

后續工作計劃。

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

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

(3)主管級別員工

這一類員工實則是與核心開發員工差不多。在核心開發員工上面進行一層工作的協調分配的工作。

六、職責清晰

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

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

七、績效考核

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

八、上下關系

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

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

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

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

以上都是自己瞎逼逼的一些總結。

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