? ? ? ? 需求來源于問題。（轉(zhuǎn)載請指明出于breaksoftware的csdn博客）

? ? ? ? 之前有個(gè)人做前端開發(fā)的同學(xué)在群里問“C語言能做什么？能寫網(wǎng)頁么？”，然后大家就開始基于這個(gè)問題展開爭辯。有的認(rèn)為是“不能，從來沒聽說過C語言能寫網(wǎng)頁”；有的說“能，連瀏覽器都是C寫的”。我想這是基于不同層面做出的回答。如果僅僅從語言層面來說，C的確寫不出網(wǎng)頁。但是從底層來說，C語言是可以做到的——大不了它自己設(shè)計(jì)一套描述語言來描述網(wǎng)頁。

? ? ? ? 但是又有幾個(gè)人會(huì)嘗試使用C語言去定制一個(gè)瀏覽器內(nèi)核并繪制“網(wǎng)頁”呢？

? ? ? ? 所以我們不可能找到一項(xiàng)可以勝任所有場景的技術(shù)，于是“在一定的場景下，PHP是最好的語言”可能并不是一個(gè)笑話。

? ? ? ? 我們工作也摻雜著很多的場景，這些場景包括：同事技術(shù)棧和基礎(chǔ)知識功底，業(yè)務(wù)特征和資源消耗類型及難點(diǎn)等。

? ? ? ? 舉個(gè)例子。記得之前看過一篇Go語言之父Rob Pike講述的關(guān)于golang誕生歷程的文章（原文：https://commandcenter.blogspot.com/2012/06/less-is-exponentially-more.html），其中他極盡嘲諷了一下C++的編譯速度，以及他認(rèn)為很奇怪的一些特性。于是在他的預(yù)想的場景下，產(chǎn)生了設(shè)計(jì)新語言的需求。最終我們在golang中的確看到了“簡單”這個(gè)特點(diǎn)。但是比較諷刺的是，他希望借此吸引C++程序員的愿望并沒有達(dá)成，但是吸引力很多PHP或者Java語言棧的同學(xué)。

? ? ? ? 可以見得，有的時(shí)候我們發(fā)現(xiàn)的問題可能比較明確，解決的方案可能也非常恰當(dāng)，但是最終可能在另外一個(gè)領(lǐng)域或者場景下取得不錯(cuò)的成果。這樣的例子還包括最近在人工智能領(lǐng)域大火的Python。

? ? ? ? 當(dāng)一個(gè)東西火起來之后，人們就開始思考它是否“放之四海而皆準(zhǔn)”。我們在網(wǎng)上看到很多關(guān)于golang好不好的爭論，個(gè)人覺得“只有適不適合”，而不存在“好不好”的問題。

? ? ? ? 回到框架設(shè)計(jì)上面來說。我們需要先定義當(dāng)前的場景、問題，然后找到一個(gè)恰當(dāng)?shù)姆桨浮?/p>

? ? ? ? 為了讓此系列文章有繼續(xù)寫下去的意義，我假設(shè)當(dāng)前的場景是：

• 團(tuán)隊(duì)成員只有PHP語言基礎(chǔ)和經(jīng)驗(yàn)
• 團(tuán)隊(duì)成員對C/C++了解僅限于大學(xué)教程，其他語言不會(huì)
• 團(tuán)隊(duì)成員對多線程編程不了解，對操作系統(tǒng)了解很少
• 項(xiàng)目需要在半個(gè)月內(nèi)完成
• 項(xiàng)目是CPU密集型網(wǎng)絡(luò)服務(wù)，經(jīng)調(diào)研，在當(dāng)前資源下PHP不足以支撐
• 項(xiàng)目的主要特征是網(wǎng)絡(luò)數(shù)據(jù)獲取并統(tǒng)籌計(jì)算，數(shù)據(jù)量不是很大
• 不能使用Go語言

? ? ? ? 除了最后一點(diǎn)，很多團(tuán)隊(duì)可能都會(huì)遇到。但是如果沒有最后一條，可能這個(gè)系列也不存在寫下去的意義。

? ? ? ? 很顯然，希望突擊培訓(xùn)成員的C/C++、多線程編程和操作系統(tǒng)基礎(chǔ)是不太可能的。即使這么短的時(shí)間內(nèi)可以讓大家寫出代碼，但是代碼質(zhì)量和維護(hù)性需要打上大大的問號，這對一個(gè)項(xiàng)目管理來說是非常不可控的。

? ? ? ? 那怎么辦？這個(gè)時(shí)候可能就需要我們設(shè)計(jì)一套易于使用的編程框架。它應(yīng)該

1. 把各種復(fù)雜的問題封裝起來，讓使用者對其無感。
2. 可以將復(fù)雜的問題化簡為團(tuán)隊(duì)成員經(jīng)常面對的問題。

? ? ? ? 其中第二點(diǎn)是非常重要的一種抽象，因?yàn)楫?dāng)我們?nèi)祟惷媾R未知問題時(shí)，最本能的思路是把它和已解決的問題進(jìn)行對比。然后對已知方案進(jìn)行修改和組合，以解決未知問題。

? ? ? ? 確定好基本目標(biāo)后，我們就會(huì)面臨基礎(chǔ)方案的選擇問題。以我的經(jīng)驗(yàn)，這是整個(gè)框架設(shè)計(jì)和開發(fā)過程中最最煩躁的過程。因?yàn)槲覀兠媾R著很多種選擇，比如

• 查找各種基礎(chǔ)的框架
• 平行基礎(chǔ)框架的性能對比，
• 平行基礎(chǔ)框架的易用性、穩(wěn)定性和可維護(hù)性
• 我們選擇約束什么，約束到什么程度
• 我們決定放開什么，放開到什么程度

? ? ? ? 很多似是而非的問題，很可能沒法做到定量分析和對比。于是框架的設(shè)計(jì)者的經(jīng)驗(yàn)、偏好和哲學(xué)就會(huì)發(fā)揮作用。

? ? ? ? 略掉中間過程，假設(shè)我們最終選定brpc作為網(wǎng)絡(luò)框架（使用見《brpc介紹、編譯與使用》）。現(xiàn)在就需要基于它來解決一些設(shè)計(jì)問題了，我們只以“多線程”這個(gè)問題為例。

? ? ? ? 讓我們的成員熟悉多線程編程？不現(xiàn)實(shí)，很多寫了很多年的老手也經(jīng)常在線程同步上栽跟頭。

? ? ? ? 編寫一個(gè)線程池？不太好，雖然避開了線程管理的問題，但是還是保留了線程的概念。而且目前場景下，有足夠的時(shí)間來寫一個(gè)超越brpc中使用的bthread的庫么？

? ? ? ? 直接使用brpc中的bthread?不太好。因?yàn)榭梢詤⒁娢臋n（https://github.com/brpc/brpc/blob/master/docs/cn/bthread.md），其中提到一句“你不應(yīng)該直接調(diào)用bthread函數(shù)，把這些留給brpc做更好”。

? ? ? ? 那怎么解決？回顧之前提到的哲學(xué)：將未知問題轉(zhuǎn)化成已知問題。我們是不是可以把每個(gè)異步過程看成一次請求呢？

? ? ? ? 具體的做法是，服務(wù)開啟一個(gè)內(nèi)部端口，原來需要獨(dú)立線程執(zhí)行的過程變成該端口下的一個(gè)服務(wù)策略提供服務(wù)。

? ? ? ? 這樣我們就將多線程問題抽象成一個(gè)請求，將團(tuán)隊(duì)成員未知的問題變成了已知。

? ? ? ? 當(dāng)然，會(huì)有很多人提出異議。比如這么做是否最好？參數(shù)序列化的代價(jià)？不可否認(rèn)這些都是問題，但是在之前介紹的場景下，這個(gè)方案不算差的。

總結(jié)

以上是生活随笔為你收集整理的从0开始搭建编程框架——思考的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。