<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Architecture &amp; Design on Mi&amp;Bee Blog</title><link>/en/posts/architecture/</link><description>Recent content in Architecture &amp; Design on Mi&amp;Bee Blog</description><generator>Hugo -- gohugo.io</generator><language>en</language><managingEditor>蓝宝石的傻话</managingEditor><lastBuildDate>Mon, 10 Jan 2022 00:00:00 +0000</lastBuildDate><atom:link href="/en/posts/architecture/rss.xml" rel="self" type="application/rss+xml"/><item><title>From Bottleneck Breakthrough to Platform Governance — The Full Evolution of an Internet Company's Monitoring Platform Architecture</title><link>/en/posts/architecture/monitor-system-architecture/</link><pubDate>Mon, 10 Jan 2022 00:00:00 +0000</pubDate><guid>/en/posts/architecture/monitor-system-architecture/</guid><description>&lt;p&gt;In the context of rapid internet business expansion, multi-cloud deployment, and exponential asset growth, the monitoring platform is a critical infrastructure for ensuring service stability. This article provides a complete review of &lt;strong&gt;a major internet company&amp;rsquo;s monitoring platform evolution from 2019 to 2021&lt;/strong&gt; — from solving legacy monitoring performance bottlenecks, to implementing cross-cloud distributed monitoring, to cloud-native platform governance — presenting the full transformation of the monitoring system from &lt;strong&gt;0 to 1 build → large-scale expansion → platform governance&lt;/strong&gt;.&lt;/p&gt;</description></item><item><title>Hybrid Cloud Cross-Region Monitoring System Governance: Autonomous + Unified Dual-Core Architecture Practice</title><link>/en/posts/architecture/monitor-cloud-architecture/</link><pubDate>Mon, 10 Jan 2022 00:00:00 +0000</pubDate><guid>/en/posts/architecture/monitor-cloud-architecture/</guid><description>&lt;p&gt;In the context of global business expansion and large-scale hybrid cloud deployment, &lt;strong&gt;cross-IDC, cross-border, multi-cloud heterogeneous&lt;/strong&gt; monitoring governance has become a core challenge for stability assurance. Traditional monitoring solutions either rely on expensive dedicated line upgrades that intrude on business architecture, or cannot balance node autonomy with global unification. Meanwhile, as a non-revenue infrastructure, the monitoring system must strictly control resource usage without allowing capability degradation.&lt;/p&gt;
&lt;p&gt;This article breaks down a practical &lt;strong&gt;cross-region monitoring system governance solution&lt;/strong&gt; from a real internet company, explaining how to achieve &lt;strong&gt;elastic scaling, cross-border coverage, node autonomy, and data unification&lt;/strong&gt; for the monitoring system without modifying business architecture or incurring business cross-domain costs.&lt;/p&gt;</description></item><item><title>Black-box Probing Monitoring System Architecture Design and Practice for Internet Companies</title><link>/en/posts/architecture/blackbox-system-architecture/</link><pubDate>Tue, 31 Aug 2021 00:00:00 +0000</pubDate><guid>/en/posts/architecture/blackbox-system-architecture/</guid><description>&lt;p&gt;In the full-link monitoring system of internet services, &lt;strong&gt;white-box monitoring&lt;/strong&gt; focuses on proactively uncovering potential issues and predicting risks, while &lt;strong&gt;black-box monitoring&lt;/strong&gt; is fault-oriented, rapidly detecting problems that have already occurred online. The two work together to form a complete monitoring闭环. Most internet companies have long had a monitoring blind spot for &lt;strong&gt;public network services and the user-side last mile&lt;/strong&gt;. User-side faults often only trigger investigation after users report issues. The black-box probing monitoring system was designed precisely to solve this industry pain point.&lt;/p&gt;</description></item><item><title>Monitoring System Enterprise Architecture Evolution — Probing Monitoring</title><link>/en/posts/architecture/prometheus-evolution-history-three/</link><pubDate>Sat, 12 Dec 2020 00:00:00 +0000</pubDate><guid>/en/posts/architecture/prometheus-evolution-history-three/</guid><description>&lt;h2 id="recap"&gt;Recap&lt;/h2&gt;
&lt;p&gt;In &amp;ldquo;Monitoring System Enterprise Architecture Evolution — Cross-Region Hybrid Cloud&amp;rdquo;, the monitoring system had gradually matured and evolved toward enterprise-level capabilities.
This chapter briefly describes the construction of the probing capability during this period. Below is the development history of this system. During the construction of the monitoring platform, internal monitoring collection alone was insufficient to meet enterprise business needs. Before planning APM development, remote probing with black-box monitoring was also incorporated as a subsystem.&lt;/p&gt;</description></item><item><title>Monitoring System Enterprise Architecture Evolution — Cross-Region Hybrid Cloud</title><link>/en/posts/architecture/prometheus-evolution-history-two/</link><pubDate>Mon, 12 Oct 2020 00:00:00 +0000</pubDate><guid>/en/posts/architecture/prometheus-evolution-history-two/</guid><description>&lt;h2 id="recap"&gt;Recap&lt;/h2&gt;
&lt;p&gt;In &amp;ldquo;Monitoring System Enterprise Architecture Evolution — First Steps with Prometheus&amp;rdquo;, the monitoring system had already been upgraded from a single-node architecture to a single &lt;code&gt;IDC&lt;/code&gt; distributed architecture.
The content of the previous article applies to both VM-based and container-based deployments. &lt;code&gt;Prometheus&lt;/code&gt; is a product of the cloud-native era and is commonly used alongside &lt;code&gt;Kubernetes&lt;/code&gt;, but &lt;code&gt;Prometheus&lt;/code&gt; itself can also replace traditional monitoring solutions like &lt;code&gt;Zabbix&lt;/code&gt; in non-&lt;code&gt;Kubernetes&lt;/code&gt; environments.
In this article, we begin to use &lt;code&gt;Kubernetes&lt;/code&gt; deployment to upgrade the entire monitoring system architecture, making it more flexible for cross-region hybrid cloud business scenarios.&lt;/p&gt;</description></item><item><title>Large Enterprise Email System Architecture Design and Full Mail Flow Analysis</title><link>/en/posts/architecture/mail-system-architecture/</link><pubDate>Wed, 10 Jun 2020 00:00:00 +0000</pubDate><guid>/en/posts/architecture/mail-system-architecture/</guid><description>&lt;p&gt;As enterprise digitalization scales up, large organizations demand extreme capabilities from email systems: &lt;strong&gt;independent deployment, high availability, global interoperability, security protection, and load balancing&lt;/strong&gt;. This article breaks down the practical architecture of a dedicated large enterprise email system, covering overall design, physical/logical deployment, core service systems, and the full send/receive mail flow, providing a reference technical solution for enterprise-level email architecture implementation.&lt;/p&gt;
&lt;h2 id="i-overall-system-architecture-design"&gt;I. Overall System Architecture Design&lt;/h2&gt;
&lt;p&gt;Large enterprise email systems adopt a layered architecture of &lt;strong&gt;&amp;ldquo;frontend gateway layer + load balancing layer + core service layer + backend independent mail system&amp;rdquo;&lt;/strong&gt;, balancing security isolation, traffic scheduling, and business independence. The overall architecture is as follows:&lt;/p&gt;</description></item><item><title>Monitoring System Enterprise Architecture Evolution — First Steps with Prometheus</title><link>/en/posts/architecture/prometheus-evolution-history-one/</link><pubDate>Thu, 12 Dec 2019 00:00:00 +0000</pubDate><guid>/en/posts/architecture/prometheus-evolution-history-one/</guid><description>&lt;p&gt;&lt;code&gt;Prometheus&lt;/code&gt; is an open-source monitoring and time series database system that has gained widespread adoption in recent years.
The official architecture diagram is shown below:
&lt;img src="/posts/architecture/images/prometheus-architecture.svg" alt=""&gt;
This series of articles will gradually understand and deepen various components and concepts through the deployment architecture evolution of &lt;code&gt;Prometheus&lt;/code&gt; in an enterprise.
First, let&amp;rsquo;s get a quick overview of this evolution history through the diagram below:
&lt;img src="/posts/architecture/images/monitoring-system-2019-2020.png" alt=""&gt;&lt;/p&gt;
&lt;h2 id="single-node-architecture"&gt;Single Node Architecture&lt;/h2&gt;
&lt;p&gt;When first getting started with the &lt;code&gt;Prometheus&lt;/code&gt; monitoring system, you only need to deploy the &lt;code&gt;Prometheus&lt;/code&gt; binary on the server side, using the basic file service discovery configuration &lt;code&gt;file_sd_config&lt;/code&gt; to pull metrics from &lt;code&gt;node_exporter&lt;/code&gt; for basic host monitoring.
Then configure the &lt;code&gt;Prometheus&lt;/code&gt; &lt;code&gt;url&lt;/code&gt; address as a &lt;code&gt;datasource&lt;/code&gt; in &lt;code&gt;Grafana&lt;/code&gt; to start viewing monitoring data.&lt;/p&gt;</description></item></channel></rss>