來源|阿里巴巴云原生公眾號

主筆 | 在德（阿里巴巴技術專家）、佳旭（阿里巴巴技術專家）
聯合作者 | 杭羽、照前、嶺峰、大猿

云原生被認為是云計算的重要發展趨勢，并且已經成為數字新基建必不可少的一個組成部分。每年的阿里巴巴 雙11 都是考驗各種前沿技術的最佳“實戰場”，而今年云原生技術在 雙11 中的大規模應用，充分證明了云原生技術的動力與前景。

本文會系統講解聚石塔在 2019 年 7 月份以阿里云容器服務為基礎設施，進行云原生實踐的探索和經驗、帶來的價值與改變，及其在 雙11 中的應用，希望對云原生化樹立可以借鑒使用的案例和樣板。

聚石塔業務背景與介紹

聚石塔最早上線于 2012 年，是阿里集團為應對電商管理和信息化挑戰，幫助商家快速解決信息化建設與管理的瓶頸打造的一款開放電商云工作平臺。它的價值在于匯聚了整個阿里系的各方資源優勢，包括阿里集團下各個子公司的平臺資源，如淘寶、天貓、阿里云等，通過資源共享與數據互通來創造無限的商業價值。

依托于聚石塔，各種業務類型（如 ERP、CRM、WMS 等業務）的服務商為淘寶、天貓等淘系的商家提供服務，服務商需要遵循聚石塔平臺的發布規則、數據安全、穩定性建設等要求。這種關系決定了聚石塔平臺的技術和架構，更直接決定服務商的技術演進方向和先進性。

聚石塔業務痛點

聚石塔承接的業務大類可以分為兩個部分：

• 傳統電商鏈路中，訂單服務鏈路上的系統：比如 ERP 系統，CRM 系統，WMS 系統。
• 電商行業中直接面向客戶的小程序場景，比如手淘與千牛客戶端的小程序業務。

綜合聚石塔的的業務類型，存在如下的業務痛點：

1. 標準化和穩定性問題

對于訂單服務鏈路的系統而言，穩定性永遠是最前面的“1”，一個系統抖動可能就會導致訂單履約鏈路中斷甚至造成資損以及客訴。穩定性和標準化是不分家的，相信大家對此對有強烈的感受。而此類系統的開發語言不統一，有 Java、PHP、.Net 等；技術棧復雜，涉及 Windows 系統、Linux 系統、單體應用、分布式應用，可謂五花八門。因此需要一套跨語言、跨平臺的通用 PaaS 平臺來解決應用的標準化、運維的標準化問題，并提供通用的鏈路問題觀測手段，來幫助服務商和平臺規范發布運維操作，發現鏈路問題，消除穩定性隱患。

2. 突發流量下的彈性問題

對于應用小程序的業務系統而言，最大的挑戰就是需要應對突發流量以及流量的不確定性。尤其在 雙11 期間，手淘端各類小程序插件會面臨比平時多十倍甚至百倍的流量。面對這種不確定性的流量洪峰，聚石塔需要一套可以實現流量預估、流量觀測、流量控制以及標準應用快速擴縮容的 PaaS 平臺。對于訂單服務鏈路的系統而言，彈性能力也是關鍵點，在原來的架構下擴容需要經歷創建虛擬機資源、部署并配置應用等諸多環節，服務商普遍感覺流程長、效率低。以上我們都總結為彈性能力的挑戰。

3. 效率和成本的問題

聚石塔在云原生之前的應用部署基本都是基于 VM 直接部署進程，這種方式缺乏進程間的資源隔離。同時當 ECS 數量變多，資源的統一管理就變得非常復雜，很容易造成資源爭搶導致應用穩定性問題以及資源浪費導致的多余成本開銷。同時，在傳統的 VM 部署模式中，應用的擴縮容不僅僅需要處理應用的代碼包啟動，還需要處理應用的端口沖突，應用所關聯的存儲資源分配，應用流量在 SLB 的掛載和摘除，應用配置的分發以及持久化，整個部署過程會變得非常耗時且容易出錯。

聚石塔云原生落地方案

針對上述的業務痛點，聚石塔開始探索技術演進方向以及系統性的解決方案，以便為淘系服務商帶來服務上質的提升。云原生帶來的技術紅利，比如應用環境標準化、DevOps 思想、彈性伸縮、跨語言的服務化能力以及運維自動化等，都不僅可以幫助聚石塔的服務商解決現存架構中的穩定性和成本問題，同時也可以幫助我們引導服務商實現技術架構的升級。

因此，聚石塔進行了重新定位，主動擁抱云原生。整體來看，目前的聚石塔云原生技術底座基于阿里云容器服務，平臺目標是賦能服務商應用架構的穩定性升級，打造基于云原生的、面向業務鏈接的 DevOps PaaS 平臺。

那么，為什么聚石塔會選擇阿里云容器服務作為云原生基礎設施呢？

阿里云容器服務 ACK（Alibaba Cloud Container Service for Kubernetes）是全球首批通過 Kubernetes 一致性認證的服務平臺，提供高性能的容器應用管理服務，支持企業級 Kubernetes 容器化應用的生命周期管理。作為國內云計算容器平臺的領軍者，從 2015 年上線后，一路伴隨并支撐 雙11 發展。

ACK 在阿里巴巴集團內作為核心的容器化基礎設施，有豐富的應用場景和經驗積累，包括電商、實時音視頻、數據庫、消息中間件、人工智能等場景，支撐廣泛的內外部客戶參加 雙11 活動；同時，容器服務將阿里巴巴內部各種大規模場景的經驗和能力融入產品，向公有云客戶開放，提升了更加豐富的功能和更加突出的穩定性，容器服務連續多年保持國內容器市場份額第一。

ACK 在今年 雙11 期間穩如磐石，深度參與了 雙11 眾多領域的支撐：在阿里巴巴集團內部支撐電商后臺系統 ASI，在零售云支撐聚石塔，在物流云支撐菜鳥 CPAAS，在中間件云原生支撐 MSE，在邊緣云支持支撐 CDN 和邊緣計算，并首度支持了數據庫云原生化和釘釘音視頻云原生化。

在過去的一年，ACK 進行了積極的技術升級，升級紅利直接運用到了 雙11 中，進一步提升了 ACK 的技術競爭力和穩定性，升級包括：高性能云原生容器網絡 Terway 相比于社區社區提升 30%，高性能存儲 CSI 引入 BDF 等的支持支撐數據庫 5K 臺神龍主機對數十 PB 數據實現高效卷管理，極致彈性 ASK，Windows 容器等首次在 雙11 活動中參戰并應用等等。規模化調度方面，ACK 高效穩定的管理了國內最大規模的數萬個容器集群，是國內首個完成信通院大規模認證（1 萬節點、1 百萬 Pod）的廠商。規模化管理的技術和經驗在 雙11 中支撐了全網客戶集群 APIServer 數十萬的峰值 QPS。

因此，聚石塔選擇 ACK 容器服務，不論是從技術角度，還是業務角度，是非常合理的，雙方的合作也是強強聯合、相互賦能、共同成長。

下面內容會講到聚石塔如何使用云原生中的技術能力來解決實際的業務痛點和問題。

1. 應用和發布標準化

聚石塔上聚集了上萬的開發者，但是不論規模還是技術能力都參差不齊。因此，聚石塔亟需為用戶提供一套可以屏蔽 Kubernetes 復雜性的、易用、靈活高效的發布系統，進而降低用戶使用 Kubernetes 的門檻，幫助用戶享用云原生的技術紅利，同時滿足作為管控方對于穩定性的要求。為了應對各種不同業務形態的差異化，聚石塔通過標準化來解決，設計了一套通用的應用模型以及對應的發布規范。

1）應用模型

Kubernetes 的一個重要思想就是面向應用的 DevOps，聚石塔 DevOps 平臺一開始就是以應用為中心的 Paas 平臺，在應用模型的設計上，整體的設計原則是讓開發者人員關注應用本身，讓運維人員關注基礎設施運維，從而讓應用管理和交付變得更輕松和可控。

同時，為了滿足客戶需求的多樣性，比如對于同一個應用，SaaS 服務商為不同商家提供不同規模的應用實例數量，或部署有差異性的代碼，聚石塔在應用下支持了多環境，并支持對測試和正式環境的隔離。

2）發布

穩定性的風險很大程度上來源于變更，Kubernetes 自帶的滾動發布，雖然標準化了發布環節，但在發布期間無法暫停，即使服務起來了，可能功能和業務存在問題，最終也會隨著滾動不斷擴大影響面；對此，聚石塔設計了支持暫停的分批發布，通過提前批的“金絲雀”驗證，從而提升系統的穩定性。

以一個“無狀態”的應用為例，主要實現原理是，通過控制兩個版本的 Deployment 的滾動，來做到可暫停和金絲雀驗證。

同時，相對于其他 Paas 平臺，聚石塔需要支撐更多的客戶應用場景，還支持有狀態應用（像 Zookeeper）以及守護進程應用（比如日志采集）的分批發布，以滿足不同客戶基于成本和防鎖定層面的需求。

而對于有狀態應用，主要原理則是通過控制 Kubernetes StatefulSet 的 Partition 分區來做到分批和暫停。

另外，對于守護進程應用，則是通過對 DaemonSet 進行 Label 的調度來實現：

從而做到不同類型的應用，得到統一的操作體感和變更穩定性保障。

2. 彈性：ACK/ASK + HPA

隨著集群規模的增大，資源成本的消耗越發明顯，尤其對于流量波動較大的場景（例如電商場景），問題更加突出。用戶不可能一直把集群資源保持在高水位上，大多數情況下用戶都會把集群資源維持在足以應對日常流量的規模，并稍微冗余一部分資源，在流量高峰在來臨前進行集群資源的擴容。

對于 Kubernetes 集群來說，啟動一個 Pod 是很快的，但是對于上述場景，啟動 Pod 前需要提前擴容 ECS，使之加入集群后，才能進行擴容，而擴容 ECS 則需要數分鐘的時間。

以上的彈性能力比較弱，操作繁瑣，耗時過長，無法及時響應流量變化，并且依然會存在很多的資源浪費，消耗成本。

1）ACK/ASK?與?ECI

阿里云彈性容器實例（Elastic Container Instance），旨在用戶無需管理底層服務器，也無需關心運行過程中的容量規劃，只需要提供打包好的 Docker 鏡像，即可運行容器，并僅為容器實際運行消耗的資源付費。ECI 是 ACK 底層的一種資源形態，一個 ECI 可以看做一個 Pod，無需提前擴容 ECS，便可直接啟動。

ECI 的價格與同等規格按量付費的 ECS 價格相近，且為按秒付費，ECS 為小時級別。如果用戶僅需要使用 10 分鐘，理論上 ECI 的成本是使用 ECS 的 1/6。

如下圖所示，Kubernetes 集群通過 Virtual Node 使用 ECI，該技術來源于 Kubernetes 社區的 Virtual Kubelet 技術，無需提前規劃節點容量，不占用已購買的 ECS 資源。

2）聚石塔結合 ECI 與 HPA

為了帶給客戶更好的體驗，聚石塔基于阿里云 ACK/ASK，結合底層的 ECI 資源，以及原生 HPA 能力，為客戶帶來了更加靈活優質的彈性能力。

通過使用污點來控制一個應用的某一個環境是否可是使用 ECI，并且會優先使用集群中 ECS 資源，資源不足時才會使用 ECI，從而為用戶解決額外成本。

同時聚石塔提供了標準的 HPA 能力，以及 cronhpa 能力，幫助用戶實現根據指標的自動伸縮（例如根據 CPU 的使用情況自動伸縮 Pod 數量），以及定時伸縮的能力。

并且通過兩者的結合，在流量動態變化的過程中，無需手動購買 ECS，以及手動擴容 Pod，實現 0 運維成本。

以上能力在今年 618 前開始小范圍推廣，完美通過了 618 以及 雙11 的考驗，用戶在 雙11 期間單個應用使用 ECI 占比最高達到 90%，為用戶節約了一半的計算成本。在 雙11 期間 ECI 在電商業務場景下整體運行穩定，平均彈升時間在 15s 以內，相比 ECS 擴容至少需要 10 分鐘，大大減少了擴容的時間成本，保證業務應對峰值流量的穩定性。

3. 應用監控

在享受 Kubernetes 云原生技術帶來快速發布、彈性伸縮等便利的同時，如何做到可監控可運維也是聚石塔的核心挑戰。一個合格的監控系統需要具體準確性、實時性、可用性，提供分析和解決問題的洞察力。傳統的監控方案，大部分是自頂向下的，配置一個監控的任務、采集端點，應用的生命周期與監控任務生命周期一致，采集目標也是固定的，無論應用如何重啟、變化，對于采集任務而言只要采集端點沒有變化，那么任何的變化都是生命周期中的正常現象。與傳統應用相比，基于 Kubernetes 的云原生應用容器實例是動態調度的、生命周期短，容器上層更是難以監控的如 Deployment、負載均衡 Service 等抽象，此外，還需要底層 ECS 計算資源、實例生命周期、Kubernetes 集群自身以及集群核心組件的各個維度的監控。基于上述考慮，聚石塔充分打通阿里云云原生監控中間件產品，為聚石塔云應用提供了分層一體化監控解決方案。

以事件監控為例，介紹下阿里云事件中心如何在聚石塔 PaaS 平臺落地。

事件中心

聚石塔借助阿里云日志服務提供的集群事件采集、索引、分析、告警等能力，將集群和云應用上的各種事件進行監控和告警。事件的范圍涵蓋所有 Kubernetes 原生 event、集群組件 event 以及其他各種定制的檢查。通常比較關心的是會影響云應用正常運行的一些異常情況，比如 Node 節點不可用、資源不足、OOM 等，比如 Pod 實例容器重啟、驅逐、健康檢查失敗、啟動失敗等。PaaS 平臺上云應用實踐過程。

• 用戶為集群一鍵安裝 NPD 組件，為集群和應用分別配置告警規則，設置關注的事件類型和通知方式即可。
• 集群上所有事件自動采集到 SLS 日志服務，日志服務上的告警規則由我們根據事件類型和用途自動配置。
• 日志服務告警回調之后，由我們統一分析處理后進行消息推送。

事件監控和告警功能，不僅能在日常幫助用戶排查和定位自身應用問題，也為平臺對各個應用的運行情況有較好的了解，從而制定個性化的優化方案以及大促保障方案。此外，對于集群底層的組件，也可以通過配置相應的規則進行告警通知，此次 雙11 大促，聚石塔為核心集群自動配置了集群 DNS 組件的告警，以便及時擴容或者切換更高可用的 DNS 方案，從而確保業務穩定。

4. DNS?生產環境優化實踐

由于聚石塔的用戶大多是電商或小程序的場景，流量波動明顯，并且開發語言多樣化，有些語言沒有很好的連接池，導致每一次請求都需要進行一次 DNS 解析。Kubernets 默認的 CoreDNS 在高并發時會遇到性能瓶頸，部分用戶在日常活動中，已經遇到了 DNS 性能的問題，更不要說 雙11 期間，因此聚石塔對 DNS 的性能做了深入的優化，確保 雙11 的穩定性。

1）Node Local DNS

默認的 CoreDNS 方式是采用的 Deployment 方式部署的無狀態服務，集群中的 Pod，通過 service 對其進行訪問。通過上述流程可以看到，DNS 解析需要跨節點請求，性能不是很高，在高并發的場景下，容易達到瓶頸。

為了進一步提高性能，阿里云提供了 ack-node-local-dns。原理如下，通過 DaemonSet 的方式，將 DNS 解析的服務在每個節點上啟動一個實例，同時設置相應的 轉發規則，將 Pod 發出的 DNS 的請求轉發到各自節點上對應的 DNS 解析服務，從而避免了跨節點的訪問，很大程度上提高了性能。

聚石塔對該插件進行了相應封裝，可以使用戶無感知的在兩種方式間進行切換。

2）Sidecar DNS

對于 ECI 的場景，由于不存在真實的宿主機，因此無法采用上述 Node Local DNS 的方案提高 DNS 性能，同時各個節點上的服務數量不同，并且不同應用對的 dns 解析并發量的不同，在極端的場景下可能會出現 DNS 解析并發量分布不均，從而導致部分節點上 DNS 解析出現問題。

基于以上場景，聚石塔結合 Kubernetes 提供的 sidecar 能力，提供了 sidecar dns。原理如下圖所示。

通過在 Pod 容器組中加入 DNS 解析服務容器。實現容器組中，其他容器所有的 DNS 解析請求均通過 sidecar dns 獲取。sidecar dns 可以看做是業務容器的緩存，只為自身所在的 Pod 提供服務，不會存在負載分配不均的問題，并且可以為 ECI 提供相應的 dns 解決方案。

5. Windows 場景落地

全球范圍內來看，Windows 的市場份額還不容小覷，在 StackOverflow 2020 最新的開發者調研中，在最受歡迎的的框架、開發包和工具中，.Net 的占比超過了 35%；在最受歡迎的編程語言中，C# 雖然有所下滑，仍保持在 30% 以上。隨著云原生的接受度越來越高，越來越多的傳統行業也對容器等云原生技術的呼聲越來越高，迫切需要更好的支持。

1）限制

Kubernetes 最先是在 1.14 版本 GA 實現了 Windows Server 2019 上進程容器的調度，隨著后面的不斷迭代，Windows 容器在調度、安全、網絡、存儲和鏡像管理等模塊上都有了很大的進步，正在慢慢對齊 Linux 容器的功能并盡最大努力保持對異構容器管理的統一性。但我們還是能看到 Windows 容器有很多的限制，這種限制更多的是來自于操作系統層面的。

• 隔離不徹底

目前 Windows 容器的實現模式分為：“進程容器"和"Hyper-V 容器”。"進程容器"是通過任務名管理來模擬資源隔離的，所以這種隔離是不徹底的，最常見的限制就是沒法 OOM kill。而"Hyper-V 容器"是通過內核隔離技術來實現，因此這種隔離是最徹底的。

Kubernetes 默認支持的是"進程容器"，其實說"只支持"都不為過，為什么呢？因為目前能支持"Hyper-V 容器"的運行時只有 Dokcer EE，而又受限于其實現，"Hyper-V 容器"不能支持 Multiple Container one Pod 的場景，再加上微軟把節點上可以跑"Hyper-V 容器"的數目也 License 化，這就極大的阻礙了"Hyper-V 容器"Kubernetes 化的進程。

• 升級難平滑

為了提高迭代效率，加速功能沉淀，微軟在 2017 年推出一種新的系統發布里程：“半年通道版”（Semi-Annual Channel）。相比于"長通道版"（Long-Term Servicing Channel），"半年通道版"是按照半年一次來進行 release 的，所 release 的內核是完全兼容當前所支持的 "長通道版"的操作系統。比方說，Windows Server 1809 SAC，Windows Server 1903 SAC ，Windows Server 1909 SAC 等都屬于 Windows Server 2019 LTSC。

比起"長通道版"，顯然"半年通道版"來得更加敏捷高效，但是轉而來的是更復雜的升級管理。

• 嚴格內核版本要求的"進程容器"：由于進程容器是通過任務名模擬的，這就導致了容器的 base 鏡像內核版本必須等于節點內核版本。換句話說，1903 SAC 的容器是沒法跑在 1809 SAC 的節點上，反之亦然。

• 有限兼容的"Hyper-V 容器"："Hyper-V 容器"的向后兼容是有限制的。比方說，在 2004 SAC 的容器上，通過 Hyper-V 技術創建的容器，只能兼容 2014 SAC，1909 SAC 和 1903 SAC，而無法運行 1809 SAC。

• 安全管理困境：當碰到安全補丁的時候，問題會變得更麻煩，除了節點要打安全補丁以外，容器也要重新re-package。詳情可以參看：https://support.microsoft.com/en-us/help/4542617/you-might-encounter-issues-when-using-windows-server-containers-with-t。

• 文件難管理

目前的 Windows 容器的文件管理比較 tricky。由于 Docker EE 只實現了主機目錄級別的掛載，這就導致 Windows 要讀寫某個文件的時候，必須把其整個目錄掛載進來。于此同時，由于主機的 ACL 管理不能被投影到容器內，這就導致了 Windows 容器對文件的權限修改是不能被主機所接收的。

在 Secret 資源的管理上，在 Linux 上請求掛載的 Secret 資源會被暫存到內存里面，但由于 Windows 不支持掛載內存目錄，所以 Secret 資源的內容會被放置在節點上。這就需要一些額外的機制來對 Secret 資源做控制。

2）展望

不過隨著這幾年的努力，我們正在迎來一個更加穩定和成熟的 Kubernetes Windows 解決方案。

• 在運行層面，ContainerD 會加速替代 Docker EE。目前社區在 ContainerD 上集成了 HCS v2，實現了對單獨文件的掛載和容器優雅退出的管理，在 v1.20 上將會實現對 GPU 和 GMSA 的支持。另外，我們也可以看到實現"Hyper-V 容器"和"特權容器"也已位列 roadmap。
• 在鏡像層面，微軟在努力的削薄基礎鏡像層，從 1809 SAC 到 2004 SAC，整個 Windows Server Core 減少了將近一半的大小，但是功能卻越來越豐富，這是讓人非常驚喜的。這也為后期的"Hyper-V 容器"打下來良好的基礎。
• 在功能層面，隨著 privileged proxy 模式的興起，很多之前沒法容器化運行的方案都找到了合適的解決方式。比方說，CSI Windows 的實現方案，就是借力于?https://github.com/kubernetes-csi/csi-proxy?的實現。
• 在運維層面，借助于 Kubernetes 的能力，完全可以打造一套 CICD 流來解決掉升級平滑的問題。

聚石塔上的傳統電商鏈路中，訂單類的各類 ERP、CRM、WMS 等系統，使用 Windows 技術棧開發的占了一半以上。如何幫助 Windows 場景下的系統進行云原生升級改造，對我們也是一個全新的挑戰。半年來，聚石與阿里云 ACK 技術團隊一起做了許多嘗試，使用阿里云 ACK 集群 + Windows 節點池作為底層基礎設施，聚石塔 PaaS 已經能夠提供完整的發布部署、負載均衡、基礎監控、擴縮容等功能。在今年的 雙11 大促中，已經有不少客戶的系統運行在 Windows 容器之上，平穩渡過 雙11 的業務高峰。

當然，Windows 場景下還有其他一些特性暫不支持，比如 NAS 共享存儲、日志采集、彈性伸縮、事件監控等，雙11 之后，聚石塔與與阿里云 ACK 會繼續一起努力，為 Windows 容器的成熟和市場化貢獻更大的技術和業務價值。

云原生帶來的業務和技術價值

在正在進行中的 2020 年 雙11 大促中，聚石塔云應用 PaaS 已經落地開花，聚石塔的核心服務商的核心系統也基本完成了云原生化的改造。

在 雙11 第一波高峰中，構建在阿里云 ACK 之上的聚石塔云原生規模達到了上萬核 CPU，上千個集群，承載 2 萬個 Pod。基于 Kubernetes，聚石塔 PaaS 封裝的應用與運行環境的標準化，發布部署以及流量變更流程標準化已經成為聚石塔服務商日常軟件交付流程中必不可少的一部分，通過這些努力聚石塔最大限度的減少了 雙11 期間不必要的應用變更，將聚石塔的變更數量減少為日常的十分之一，保證線上系統穩定性；同時我們推動聚石塔 PaaS 上的核心應用完成了基于閾值（CPU，內存，load）以及基于集群事件（比如 Pod 驅逐，節點不可用）的監控告警，實現了線上問題先于客戶發現，及時解決止損；對于小程序的突發流量應用場景，聚石塔在普通 Kubernetes 集群內引入了 vnode 和 ECI 的技術，保證集群資源不足的情況下，可以實現 Pod 的秒級快速應急彈縮，應對突發的流量洪峰。

云原生帶來的價值不止于此，基于聚石塔的用戶反饋，云應用 PaaS 普遍給開發者帶來了 30% 以上的研發效能提升，應用的擴縮容甚至實現了小時級到秒級的時間縮短；同時基于容器的運行環境以及計算資源標準化抽象，給大多數用戶帶來了 30% 以上的計算資源成本節約。基于云原生的架構與運維規范也推動了服務商自身的軟件架構升級，比如從單體應用向分布式應用的升級，從垂直擴縮的有狀態應用向可橫向擴縮的無狀態應用的升級。

云原生在電商垂直業務下的實踐才剛剛起航，后續聚石塔還將持續在云原生技術領域深耕，在應用運維標準化 OAM，應用鏈路的可觀測性，基于 Mesh 的應用流量監測和控制，基于業務指標的彈性伸縮，分布式應用壓測與容災等領域繼續探索，將云原生的技術價值賦能給客戶和業務，同時將電商垂直領域的云原生技術實踐反哺云原生社區。

總結

以上是生活随笔為你收集整理的「云原生上云」后的聚石塔是如何应对 双11 下大规模应用挑战的的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。