2024 年的最佳 PHP 框架

原创 21CTO
在本文中,我們將預測在 2024 年繼續流行的最佳 PHP 框架。

我們首先將看看PHP框架是什麼,什麼時候該考慮使用PHP框架,以及使用PHP框架的主要優點都是什麼。

我也會介紹最適合初學者的 PHP 框架以及用於 Web 開發的最佳框架。

什麼是PHP框架?

在我們了解使用 PHP 框架的優點以及哪些是最好的 PHP 框架之前,我們先了解什麼是 PHP 框架。

PHP是世界上使用最多的伺服器端程式語言,PHP框架也已經存在了很長時間,並且多年來採取了不同的形式與範式。 它們為從簡單的網站到管理數百萬註冊和日常訪問的大型複雜 Web 應用程式提供動力。

PHP 框架已經使用了幾十年(Phplib,是第一個 PHP 框架,可以追溯到 2000 年之前),它們採取了不同的形式,但它們的主要目的基本上保持不變。 其目的是:透過提供常用函數集以及常用功能庫來幫助 PHP 開發者,並強制使用最佳編碼實踐。

將 PHP 框架想像成一個已經提供了一個正在運行的原始級系統,你可以在其中嵌入自己的程式碼,而無需從頭開始遍歷每個細節。 例如安全性身份驗證? 已經搞好了! 路由? 是的! 依賴注入? 不需要考慮!

透過使用框架,開發者可以大幅減少編寫所需的程式碼量並提高工作效率,同時由於使用程式碼標準和最佳實踐,還可以確保高水準的軟體品質。

探索框架的功能也能幫助我們發展技能的提高,是 PHP 學習的另一種好方法。

什麼時候用 PHP 框架

儘管現在對PHP程式設計師來說,在幾乎每個專案中使用框架似乎都是不費吹灰之力的事兒。 但是在許多情況下,使用PHP框架可能不是最好的主意。 這完全取決於項目。

大多數時候,討論都圍繞著使用什麼框架,而很多時候的討論,應該圍繞著我們是否應該使用一個框架。
框架的主要優勢

雖然在一些極端情況下,使用 PHP 框架並不是解決問題的最佳解決方案,但是,使用框架好處還是要多一些。

首先,我們不必花費時間和精力來規劃應用程式架構、評估各種可用的程式庫並從頭開始實現架構,而是透過使用框架,我們會得到一個功能齊全的模板,而只需要專注於建立特定於 項目的功能。

除此之外,許多 PHP 框架還包括命令列工具,這些工具有助於產生自動程式碼模板,從而進一步加快開發速度。

開發PHP應用程式時最大的問題之一是安全性。 大多數開發者沒有配備創建安全 PHP 應用程式所需的所有工具或技能。 透過使用 PHP 框架,我們使用的解決方案由社群不斷測試、審查和審查。 由於它們中的大多數都是開源的,因此安全問題通常很快就會被注意到並修復。

作為開發者,我們應該牢記技術解決方案和實現方式。 但是當我們在團隊中工作時,情況就會發生變化,因為每個人的解決問題思維將會有所不同。 如果不了解設計決策和程式碼庫的完整文檔,團隊成員會發現程式碼很難使用,有時甚至難以理解應用程式的程式碼邏輯。

使用 PHP 框架可以讓新任開發者更容易開始專案。 即使他們還不熟悉該框架,他們也可能會存取該框架的完整文檔,以及有關如何在 Web 上使用它的影片和教學課程。 這樣開發人員可以專注於開發功能,而不是在整個專案中不斷指導新的團隊成員。

有哪些好PHP框架

PHP框架的世界在過去十年中迅速發展。 就在過去的幾年裡,我們看到了一些穩定的趨勢。

因此,一些框架已成為大多數軟體開發專案的首選。

其實不斷成長的PHP框架清單並非只有五個。 還有一些框架會更適合特定情況,有更快的學習曲線/社群支援等。 在創建這樣的受歡迎清單時,我們會考慮到這些因素,並選擇那些在整體上表現更好的因素。

有了這些警告,你就會知道我們是怎麼排的,然後就來看看 2024 年最值得使用的五個 PHP 框架。

Laravel

以下介紹來自Laravel網站:

Laravel 試圖透過簡化大多數Web 專案中使用的常見任務(例如身份驗證、路由、會話和快取)來消除開發者的一些痛苦……Laravel的目標是在不犧牲應用程式功能的情況下 ,使開發過程令人愉悅。

Laravel 可能是目前最常使用且最受使用者推薦的 PHP 框架。

它於 2011 年由 Taylor Otwell 首次發布,試圖創建一個更高級的CodeIgniter 替代品,當時它尚未提供身份驗證和授權等功能。

Laravel是一個非常廣泛且功能豐富的框架,它遵循MVC模式,並提供開箱即用的功能。
以下的介紹來自Laravel官網:

Laravel 試圖透過簡化大多數Web 專案中使用的常見任務(例如身份驗證、路由、會話和快取)來消除開發的痛苦……Laravel的目標是在不犧牲應用程式功能的情況下,使 開發過程對開發人員來說是令人愉悅的。

Laravel是一個非常廣泛且功能豐富的框架,它遵循MVC模式,並提供開箱即用的功能。 例如:

使用者認證

授權

電子郵件驗證

加密

哈希

密碼重設

在模板方面,Laravel 使用模板引擎 Blade,Eloquent ORM 涵蓋了資料庫互動。 它還使用 Artisan 命令列工具來幫助加快開發速度。

注意:ORM 代表物件關係映射器。 ORM 是一種機制,可以對資料庫物件進行尋址、存取和操作,而無需考慮這些物件與其資料來源的關係。 它本質上是一個黑盒子,用於說明如何與資料庫進行互動。

Laravel 也很容易透過 Composer 或 Homestead、Vagrant box 或 Laravel Valet 等解決方案進行安裝。

規格

發佈時間:2011 年 6 月

目前版本:9,2022 年 1 月發布。

技術要求:PHP >= 8(或使用 Laravel Homestead)

安裝:composer create-project laravel/laravel your-app-name

網址:laravel.com

文件:laravel.com/docs

Symfony

Symfony可以從兩個不同的角度來看。

首先它是一個 PHP 框架,也是用來建立 Web 應用程式的 PHP 元件集合。 由於這種多功能性,Symfony具有高度的可擴展性。 你可以使用整個框架,也可以只選擇幾個適合自己用例的元件。 它可以是簡單的,也可以是複雜的,而Symfony確實是一個偉大的軟體的證據是,大多數其他PHP框架在後台都使用了Symfony組件。

Symfony 使用 Doctrine ORM 進行資料庫交互,並使用 Twig 作為模板引擎。 它還有自己的 CLI 工具來幫助我們開發。

規格

發佈時間:2005年

目前版本:6.1.5,2022 年 5 月發布

技術需求:PHP >= 8

安裝:composer create-project symfony/skeleton:”6.1.*” my_project_directory

網址:symfony.com

文件:Symfony.com/docs

在研究 Laravel 和 Symfony 時要考慮的另一件事是,兩者都有大量的開發人員社群積極使用它們並為其開發。 兩者的文檔都非常友好且內容廣泛。

CakePHP
CakePHP 背後的想法是建立一個專注於快速開發的 Web 開發框架,使建立 Web 應用程式更簡單、更快捷,並且只需很少的程式碼。 這個想法是使用約定而不是配置來實現快速工作。 這表示並沒有 XML 或 YAML 檔案。

CakePHP 有其內建的 ORM,在模板方面,它使用自己的.ctp檔案格式,使用替代的 PHP 語法來控制其結構和輸出。

就像其他框架一樣,CakePHP 實作了安全功能,例如加密、密碼雜湊、保護表單資料和 CSRF 保護。

儘管它的社群不像 Laravel 那樣龐大和充滿活力,但仍有許多資源和活動可供 CakePHP 開發者使用。

規格

發佈時間:2005年

目前版本:4.4,2022 年 8 月發布

技術需求:PHP >= 7.4

安裝:composer create-project –prefer-dist cakephp/app:~4.0 my_app_name

網址:cakephp.org

CodeIgniter

如同 CakePHP 一樣,CodeIgniter 被發明為一個快速開發的 MVC 框架,具有最少的配置。 但它的創造者將其提升到了一個新的水平。

CodeIgniter 的佔用空間非常小(下載量為 1.2MB),這意味著它幾乎沒有臃腫多餘的程式碼,而且速度也非常快。

儘管 CodeIgniter 沒有與 ORM 捆綁在一起,但它有一個功能齊全且非常快速的抽象資料庫類,它同時支援傳統結構和查詢建構器模式。 模板也是一樣:儘管我們可以使用外部模板引擎或普通的 PHP,但 CodeIgniter 也提供有一個可以使用的類別:Template。

規格

發佈時間:2006 年

目前版本:4.1,2022 年 2 月發布

技術需求:PHP >= 7.4

安裝:composer create-project codeigniter4/appstarter your-app-name

網址:codeigniter.com

文件:CodeIgniter 文檔

FuelPHP

FuelPHP 是此列表中最年輕的框架。 它的官網這樣描述:

Fuel PHP 框架是一個快速、簡單、靈活的 PHP 5.x框架,誕生於其他框架的最佳理念,是一個全新的開始!

FuelPHP 充滿了「新」的概念和範式,例如使用 HMVC(分層模型視圖控制器)而不僅僅是 MVC。 HMVC 提供更好的程式碼組織、更大的模組化、更多的可擴充性,並鼓勵程式碼重複使用。

FuelPHP 提供了自己的 ORM 和命令列工具,並擁有一個小而熱情的社群。 儘管 FuelPHP 是所展示的框架中最年輕的,但它絕對是一個值得考慮的選擇。

規格

發佈時間:2014 年

目前版本:1.9,2021 年 12 月發布

技術需求:PHP >= 5.3

安裝:composer create-project fuel/fuel –prefer-dist .

網址:fuelphp.com

文件:fuelphp.com/docs

結論

在完成本文之前,我想先給大家一些在使用 PHP 框架時要記住的一些特點:

沒有適合所有項目的框架。 只有當它能夠解決問題時,它就是最好的。

在選擇框架時,在做出決定之前,請確保框架能夠得到支持,定期更新,並且背後有一個良好的用戶社群。

一直實踐! 請確保你感到舒適,並喜歡自己選擇的框架。 如果你對使用「最好的」框架感到有一丟丟痛苦,那麼使用它就沒什麼意義。

永遠不要停止學習! 你對框架的實踐,還有踢輪胎的次數越多,你對科技的了解就越多。

Linux 系統之 OOM 解析

Luga Lee twt企业IT社区
【摘要】基於 VM 環境所部署的 Spring Boot 應用服務,運行過程中內存利用往往達到 90% 甚至以上,本文嘗試對此類在實際業務場景中內存表現的活動現象及背後原因進行分析。
【作者】李傑,專注於Java虛擬機器技術、雲端原生技術領域的探索與研究,個人大眾號「架構驛站」。

在實際的業務場景中,有沒有發現這樣一種場景:基於VM 環境上面所部署的Spring Boot 應用服務,往往在運行過程中將內存利用的足夠“猥瑣”,常常達到90% 甚至以上,此時 ,很大一部分夥伴就開始「叫」了。 曰:領導,記憶不夠了,趕緊擴容! ! ! (此刻,有大佬肯定在想:擴你妹,整天搞這些沒用的~)

那個傻子是不是瘋了? 不知道身為所謂的「技術」人員,大家是如何面對的,如何解決? 本文將聚焦於 Linux 記憶體結構、記憶體分析以及 OOM killer 等 3 個面向以及筆者多年的實務經驗總結來進行解析。

記憶體結構

從宏觀角度而言,記憶體管理系統是作業系統最重要的部分之一。 在記憶體管理的系統呼叫方式,事實上,基於 POSIX 並沒有給記憶體管理指定任何的系統呼叫。 然而,Linux 卻有自己的記憶體系統調用,主要係統調用如下:

系統呼叫 描述
s = brk(addr) 改變資料段大小
a = mmap(addr,len,prot,flags,fd,offset) 進行映射
s = unmap(addr,len) 取消映射
1、brk 透過給出超過資料段之外的第一個位元組位址來指定資料段的大小。 如果新的值要比原來的大,那麼資料區就會變得越來越大,反之會越來越小。

2、mmap 和 unmap 系統呼叫會控制映射檔。 mmp 的第一個參數 addr 決定了檔案對映的位址。 它必須是頁面大小的倍數。 如果參數是 0,系統會指派位址並傳回 a。 第二個參數是長度,它告訴了需要映射多少位元組。 它也是頁面大小的倍數。 prot 決定了映射檔的保護位,保護位可以標記為 可讀、可寫、可執行或這些的結合。 第四個參數 flags 能夠控製檔案是私有的還是可讀的以及 addr 是必須的還是只是進行提示。 第五個參數 fd 是要對應的檔案描述子。 只有開啟的檔案是可以被映射的,因此如果想要進行檔案映射,必須開啟檔案;最後一個參數 offset 會指示檔案從何時開始,不一定每次都要從零開始。

針對 Linux 記憶體管理及實現,其實其涉及的面較廣,較為複雜,從電腦早期開始,我們在實際的業務場景中所使用的記憶體往往都要比系統中實際存在的記憶體多。 為此,記憶體分配策略克服了這個限制,而其中最有名的就是引入: 虛擬記憶體(Virtual Memory)。 透過在多個競爭的進程之間共享虛擬內存,虛擬內存得以讓系統有更多的內存,以方便維護系統資源的分配。 先來張總概覽圖,具體如下圖所示:

Linux 內存,通常被認為指的是“物理內存”,然而,只有內核才可以直接訪問物理內存,進程需要訪問內存,Linux 內核則需要為每個進程提供一個獨立的虛擬地址空間,訪問的是 虛擬記憶體。

通常而言,虛擬記憶體空間的內部被劃分為核心空間和使用者空間:

1.進程在用戶態,只能存取用戶空間內存

2.行程進入內核態才能存取核心空間內存

3.每個行程都包含內核空間,但這些內核空間都關聯相同的實體內存

而針對記憶體映射,其主要將虛擬記憶體位址映射到實體記憶體位址,為了完成記憶體映射。 核心每個進程都維護了一張頁表,記錄虛擬位址和實體位址的映射關係,頁表實際儲存在CPU 的記憶體管理單元 MMU,這樣處理器就可以直接透過硬體找出要存取的記憶體。

再來一張內核線形位址空間佈局圖,具體可參考如下「硬核」示意圖:

針對上述結構圖,簡單描述如下:

1.核心直接映射空間 PAGE_OFFSET~VMALLOC_START,kmalloc和__get_free_page()分配的是這裡的頁面。 二者是藉助 Slab分配器,直接分配實體頁再轉換為邏輯位址(實體位址連續)。 適合分配小段記憶體。 此區域 包含了核心鏡像、實體頁框表mem_map 等資源。

2.核心動態映射空間 VMALLOC_START~VMALLOC_END,被 vmalloc 用到,可表示的空間大。

3.核心永久映射空間 PKMAP_BASE ~ FIXADDR_START,kmap

4.核心臨時映射空間 FIXADDR_START~FIXADDR_TOP,kmap_atomic

記憶體分析

針對記憶體分析部分,其實可利用的手段或策略較多,基於不同段位的水平高低之分,通常,我們可以藉助Top、Free 指令以及Vmstat 指令進行追蹤及觀測記憶體的動態活動變化趨勢,以即時了解 目前作業系統的資源水位,具體如下所示:

[administrator@JavaLangOutOfMemory ~ ] %top
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
1 root 20 0 128032 7996 5556 S 80.0 80.4 0:01.03 java
2 root 20 0 0 0 0 S 0.0 0.0 0:00.00 kthreadd
基於上述輸出結果,簡單解析如下:

1、VIRI: 虛擬內存,包括了進程的代碼段、數據段、共享內存、已經申請的堆內存和已經換出的內存等,已經申請的內存,即使還未分配物理內存,也算做虛擬內存

2、RSS: 常駐內存,是進程實際使用的實體內存,不包括 Swap 和共享內存

3、SHR: 共享內存,包括與其他進程共同使用的真實共享內存,包括加載的動態鏈接庫以及程序的代碼段

4、%MEM: 進程使用實體記憶體佔系統記憶體的百分比

[administrator@JavaLangOutOfMemory ~ ] %free
total used free shared buff/cache available
Mem: 2031744 98176 1826192 8784 107376 1800144
Swap: 2097148 0 2097148
此命令列輸出內容較為簡單:主要列印已使用、剩餘、可用、共享記憶體以及快取等資訊。 部分參數釋義如下圖所示:

1、Shared: 共享記憶體, 共享記憶體是透過 Tmpfs 實現的,它的大小就是 Tmpfs 使用的記憶體大小。

2、Available: 可用內存,是新進程可以使用的最大內存,包括剩餘內存和還未使用的內存。

3、Buffer/Cache: 快取包括兩部分,一部分是磁碟讀取檔案的頁緩存,用來緩存從磁碟讀取的數據,加速以後再次存取速度,另一部分是Slab 分配的可回收快取;緩衝區是 對原始磁碟的暫存,用來快取將要寫入磁碟的數據,統一最佳化磁碟寫入。

[administrator@JavaLangOutOfMemory ~ ] %vmstat 1 1
procs ———–memory———- —swap– —–io—- -system– ——cpu—–
r b swpd free buff cache si so bi bo in cs us sy id wa st
1 0 0 1815348 2108 111872 0 0 1 0 11 11 0 0 100 0 0
基於上述輸出結果,簡單解析如下:

1、si: 換入,每秒從磁碟讀入虛擬記憶體的大小,若此值長時間持續大於0,表示實體記憶體不夠或記憶體洩漏,需要定位問題。

2、so: 換出,每秒鐘從記憶體寫入磁碟的大小,若此值長時間持續大於0,表示實體記憶體不夠用,就需要排查記憶體問題。

OOM Killer

通常有這樣的一種場景:若一台VM (虛擬機)上部署多個應用服務,此處,暫以Spring Boot 微服務為例,在某種特殊的時刻,例如:業務促銷、壓力測試或 當某一個聯機負載節點或因網路抖動而掛掉時,此台VM 上的服務突然在毫無徵兆的情況下,突然被「掛掉」。

同時,我們開始蒐集相關線索,以便能夠快速定位到問題原因,將「罪魁禍首」逮捕歸案。

那麼,為什麼會出現這種問題呢? 它是如何產生的? OOM,全稱為 “Out Of Memory”,即 記憶體溢位。 OOM Killer 是 Linux 自我保護的方式,防止記憶體不足時出現嚴重問題。

Linux 核心所採用的此種機制會不時監控所運行中佔用記憶體過大的進程,尤其針對在某一種瞬間場景下佔用記憶體較快的進程,為了防止作業系統記憶體耗盡而不得不自動將此 進程Kill 掉。 通常,系統核心偵測到系統記憶體不足時,篩選並終止某個行程的過程可以參考核心原始碼:linux/mm/oom_kill.c,當系統記憶體不足的時候,out_of_memory()被觸發,然後呼叫select_bad_process( ) 選擇一個”bad” 進程殺掉。 如何判斷和選擇一個」bad 進程呢?Linux 作業系統選擇」bad」進程是透過呼叫 oom_badness(),挑選的演算法和想法都很簡單很樸實:最 bad 的那個進程就是那個最佔用記憶體的進程。

OOM Killer 原始碼解析

OOM killer的核心函數是 out_of_memory(), 執行流程如下:

1.呼叫 check_panic_on_oom() 檢查是否允許執行核心恐慌,假如允許,需要重新啟動系統。

2.若定義了 /proc/sys/vm/oom_kill_allocating_task 即允許 Kill 掉目前正在申請分配物理記憶體的程序,那麼殺死目前程序。

3.呼叫 select_bad_process,選擇 badness score 最高的進程。

4、呼叫 oom_kill_process, 殺死選擇的進程。

我們透過分析 Badness Score 的計算函數來理解 OOM Killer 是如何選擇需要被 Kill 掉的進程,具體原始碼可參考如下所示:

unsigned long oom_badness(struct task_struct *p, struct mem_cgroup *memcg,
const nodemask_t *nodemask, unsigned long totalpages)
{
long points;
long adj;

/* 假如该进程不能被kill, 则分数返回0. */
if (oom_unkillable_task(p, memcg, nodemask))
return 0;

p = find_lock_task_mm(p);
if (!p)
return 0;

/* 获取该进程的 oom_score_adj, 这个是用户为进程设置的 badness score
* 调整值,假如这个值为-1000或者进程被标记为不可被kill,或者进程处于
* vfork()过程,badness score返回0. */
adj = (long)p->signal->oom_score_adj;
if (adj == OOM_SCORE_ADJ_MIN ||
test_bit(MMF_OOM_SKIP, &p->mm->flags) ||
in_vfork(p)) {
task_unlock(p);
return 0;
}

/* badness score分数 = 物理内存页数 + 交换区页数 + 页表Page Table数量. */
points = get_mm_rss(p->mm) + get_mm_counter(p->mm, MM_SWAPENTS) +
mm_pgtables_bytes(p->mm) / PAGE_SIZE;
task_unlock(p);

/* 利用以下公式对 badness score 值进行调整. */
adj *= totalpages / 1000;
points += adj;

/* 返回 badness score, 假如等于0, 则返回 1. */
return points > 0 ? points : 1;
}
透過對 Badness Score 計算函數的分析,我們可以發現 OOM Killer 是基於 RSS 即常駐的實體記憶體來選擇進程進行 Kill 操作, 從而釋放相關記憶體以進行系統自我保護。 有關 OOM Killer 相關配置、查看及分析將於後續文章給出,大家到時留意查看。

綜上所述,本篇文章主要透過基於對Linux 記憶體結構、分析及OOM Killer 3個核心維度,從主動及被動場景等2 面向對Linux 作業系統記憶體的剖析,以探討在實際的業務場景中, 記憶體表現的相關活動及經驗認知。

思科宣布完成對Splunk的收購

2024年3月19日,北京 —— 日前,思科宣布完成對網路安全軟體公司Splunk的收購,令思科具備更強的基礎得以服務客戶,為客戶的完整數位化足跡提供卓越的可見性和洞察力。

在數位新時代發展,企業需要全方位連結並保護其營運要素的安全,包括連結推動業務成長的人員、地點、應用、資料和設備,同時保護整個數位足跡免受網路安全威脅、停機時間和其他 關鍵業務風險的影響。

思科將整合網路解決方案、安全解決方案,和視覺化數據,充分發揮網路的全部潛能,為企業提供即時一致的完整數位景觀,幫助團隊主動保護關鍵基礎設施,預防網路中斷,並優化網路體驗。

思科將推動AI變革,保護AI變革中的網路安全
人工智慧(AI)技術的應用及其產生的影響,超越了以往我們所見的任何一項技術。

大規模有效利用適當的數據,是令AI發揮優勢並令企業以前所未有的效率達成業務目標的關鍵。 想要真正透過AI獲益,企業需要能夠支援AI算力的基礎設施、可供發展AI技術的資料、能夠保護AI安全的平台,以及可即時管理AI應用的視覺化平台。 思科在以上四個領域中皆有所長且可整合解決方案。

攜手共進:思科與Splunk將為客戶與合作夥伴帶來的優勢
思科和Splunk的結合將令我們的客戶:

更安全
高度整合的安全解決方案,充分利用雲端、網路和端點流量來實現前所未有的可見性,為各種規模的企業提供威脅預防、偵測、調查和回應能力。

更可視
高度全面的全端視覺化解決方案,在多雲混合環境中為使用者提供卓越的數位體驗。

更互聯
在智慧、有韌性和持續優化的網路基礎架構上提供領先的安全網路解決方案。
更卓越的AI
思科的網路產品組合,結合強勁安全保障、全端視覺化和全面的資料平台,使客戶能夠安全地在企業和應用中駕馭AI的力量。

更強的經濟效益

思科與Splunk的平台化方案將協助我們的客戶整合眾多單點產品,進而改善業務成果並降低成本。

思科和 Splunk 的結合,也將擁有豐富經驗的全球開發人員和合作夥伴社群聚在一起,為客戶提供預先包裝的應用程式和解決方案擴展其安全性、視覺化和資料平台功能。 結合後的合作夥伴生態系統可以透過高價值服務以及部署創新的新應用程式和人工智慧驅動的解決方案創造新的利潤。

關於思科
思科(NASDAQ:CSCO)是全球科技領導廠商,致力於安全地連接一切,使一切成為可能。 我們的目標是透過重新定義應用、賦能混合辦公、保護企業安全、基礎架構轉型,幫助客戶實現永續發展目標,為所有人打造一個包容性的未來。 您可以在cisco.com.cn上獲取更多信息,並關注我們的微信公眾號“思科聯天下”。

思科和思科標誌是思科或其附屬機構在美國和其他國家地區的商標或註冊商標。 您可以查看Cisco商標清單www.cisco.com/go/trademarks,其中提及的第三方商標是其各自所有者的財產。 使用「夥伴」一詞並不能直接表示思科與任何其他公司之間有合作關係。