Google Cloud Account Purchase: Independent Station Overseas Acceleration: Optimize Global Access Speed with Google Cloud Premium Network and Load Balancing
Friends who do cross-border e-commerce and independent stations (such as Shopify independent deployment, WooCommerce or Magento) have to deal with thousands of overseas customers almost every day.
In overseas markets, the survival lifeblood of independent stations can be summed up in one word:
Page loading speed
. According to Google's official statistics, if a mobile web page takes more than 3 seconds to load, more than 53% of users will directly choose to close the tab. For independent stations, every second of slow speed means the loss of real money and the waste of advertising fees (such as Facebook Ads and Google Ads).
In order to speed up, many independent station sellers blindly set up a layer of free CDN, or buy servers everywhere in Europe, the United States and Asia. As a result, not only the background data synchronization has become a disaster, but also the high server budget has directly bottomed out the profits.
In the ecosystem of Google Cloud(GCP, Google Cloud), there is a global acceleration trick designed for multinational high-traffic businesses, called
Advanced networking (Premium Tier) and global HTTP(S) load balancing (Global Load Balancing)
.
Today we don't talk about empty theories and reject rhetoric. Starting from pure actual combat, I will take you from zero to configure a set of large-scale global acceleration and high-availability architecture, so that your independent station can truly realize "global second opening".
The first stage: to knock down the bottom, understand Google's "Premium advanced network" dimension reduction strike
Before you start configuring, you must understand the essential differences between Google Cloud and other cloud vendors on the network, otherwise it is difficult for you to understand why web pages will become faster after using GCP.
Google has built its own huge and dense worldwide
private fiber backbone network
. Based on this foundation, GCP provides two completely different network transmission modes:
Standard network (Standard Tier): Same as common cloud vendors. When a user in new york visits your server in Taiwan, China, the traffic will first go around and jump wildly in various common operator networks of the public network, and will not enter Google's computer room until it is close to Taiwan. In this way, the network jitter is large and the delay is high.
Advanced networking (Premium Tier, turned on by default): This is Google's trump card. In the same scenario, the request of a New York user will "jump" directly into Google's internal private fiber network at the nearest Google Edge Node (PoP) in New York as the first step out of his home. The next transoceanic transmission, all on Google's own exclusive highway, until direct access to Taiwan servers.
Core Conclusion: Advanced networking minimizes the "uncertainty" of public networks. Combined with global load balancing, it enables global users to share the same static public network IP, but the network speed can be fully reached.
Phase II: Architecture Design-Independent Station Global Multi-
The "Golden Position"
Suppose your core users of independent stations are distributed in two regions:
North America
and
Southeast Asia
. In pursuit of extreme speed, we decided to adopt a "multi-center deployment" approach:
Deploy a VM virtual machine (running your WordPress/WooCommerce standalone image) in US East (us-east1 of South Carolina).
Deploy an identical VM virtual machine in Asia (asia-east1 Taiwan).
At the forefront of the two machines, a Google Cloud Global External HTTP(S) Load Balancer (Global External Application Load Balancer) is set up.
The logic of the entire flow is
: Global users visit the same URL (pointing to the same IP of the load balancer). When a user in the eastern United States opens a web page, the load balancer will automatically divert him to a server in the eastern United States. When a user in the Philippines or Singapore opens a web page, it will automatically divert it to a server in Taiwan.
If one of the Region's servers accidentally goes down, the load balancer will start an automatic fuse within a few seconds, seamlessly cutting the US traffic to Taiwan's servers, and the website will never drop.
The third stage: actual combat exercise-hand-in-hand to take you to configure global load balancing
Please make sure that you have set up a virtual machine with Nginx/Apache installed in the United States and Asia, and the contents of the independent stations on both sides are the same. Next, let's go to the front end to build the commander-load balancer.
Log in
GCP Console
, the upper left navigation menu to find
Network Services (Network Services)-> Load Balancing"
.
Click the top
Create load balancer"
.
1. Select the level mode
Select HTTP(S) Load Balancing as the load balancer type ".
Select Internet access to my virtual machine (I. e. external load balancing).
Select Global External Application Load Balancer (Global External Application Load Balancer) ".
2. Configure the back-end service (Backend Services)-bind your server.
The role of the back-end service is to tell the load balancer which "workers" (servers) are behind it.
Click Backend Configuration-> Create Backend Service ".
The name starts with standalone-site-backend.
Protocol and Port: Select HTTP (port 80) or HTTPS (port 443, depending on your server's configuration).
Add a backend instance group (Instance Groups)
: area selection us-east1, select the independent station virtual machine in your east of the United States. Click to continue to add, select the asia-east1 area, and select your independent virtual machine in Taiwan.
Configure Health Check: Extremely important! * Click Create Health Check and let the load balancer go to GET your website homepage every 5 seconds. If you don't get a response three times in a row, you think the server is "dead" and immediately stop shunting it.
3. Configure the front end (Frontend Configuration)-get the golden global IP
Front-end configuration is the user-oriented external network gate.
Click "Front End Configuration" and name site-frontend-gate.
Protocol (Protocol): HTTPS is recommended.
IP address (IP Address): The default is temporary (Ephemeral). Do not hesitate to click on the drop-down menu, select "reserve static IP address" and name global-lb-static-ip.
Certificate (Certificate): Since it is HTTPS, an SSL certificate is required. Google offers an extremely invincible feature here-free Google-hosted certificates (Google-managed certificate). Select "Create a new certificate" and enter the real domain name of your independent site (for example, www.yourshop.com). Google will automatically help you apply for, issue and renew this SSL certificate in the background. You will no longer have to toss about the certificate manually every year.
After the configuration check is correct, click at the bottom
Create"
.
The fourth stage: domain name resolution and real field verification
After clicking Create, wait a little 3 to 5 minutes for Google to synchronize the configuration of this load balancer at the edge nodes around the world.
On success, on the load balancer list page, you will see the global static external IP address assigned to you (for example, 34.120.x.x).
Log in to the background (such as GoDaddy, Namecheap or Cloudflare) where you purchased the domain name, and directly modify the public network IP pointing to this Google cloud load balancer by recording the of your independent station domain name.
Wait a few minutes for DNS to take effect.
How do you verify that acceleration and shunting are really in effect?
We utilize global multi-node testing tools (such
ping.pe
or
Catchpoint
):
When you request www.yourshop.com from nodes in New York and Boston, you will find that the request lands directly in the US East computer room within ten milliseconds.
When you request from nodes in Kuala Lumpur and Hong Kong, the traffic automatically lands in the Asia-Pacific computer room, and the latency is also surprisingly low. Global users no longer need to cross half a land
The ball pulls the data and truly achieves "nearby access and physical acceleration".
The fifth stage: the history of avoiding the pit and tears of the transnational independent station structure.
After this scheme is configured, the speed of web page opening will definitely make a qualitative leap. But when you are happy, as the technical person in charge, you must immediately start to solve the following two reality pits derived from "multi-regional deployment:
1. The ultimate problem: how to synchronize the data of both databases?
The front-end server can open multiple servers, but if the user places an order in the US East server and the database of the Taiwan server does not know, it will be completely confused.
Wrong practice: let the virtual machines on both sides install an independent MySQL, which is irrelevant to each other.
Factory standard practice: do not build your own database in a virtual machine. Directly use Google Cloud's Cloud SQL for MySQL or Cloud Spanner. Set it as the master database in the US East and cross-region read Replica (Cross-Region Read) in Taiwan. Or directly use distributed database technology to ensure that orders and inventory data of global users are synchronized at the second level without reconciliation errors.
2. Secondary drying of static resources (pictures, videos)
There are a large number of high-definition maps and detailed page videos on the independent station. If every request has to be read from the hard disk of the virtual machine, the CPU of the server will be drained instantly.
Hard core money saving optimization: in the back-end configuration of Google cloud load balancer, conveniently open Google Cloud CDN.
Operation Insider: When turned on, hundreds of Google Edge nodes around the world will automatically "intercept" and cache images and CSS style sheets on your website. When the next user in the same area visits, the traffic does not even need to be disturbed by the load balancer, and the outermost edge node spits the picture to the user. This will not only make the speed soar again, but also help you cut more than 70% of the server calculation bandwidth bill.
Summary
Using Google Cloud Premium network and global load balancing to optimize independent stations is essentially borrowing Google's "physical plug-ins" laid around the world ".
You don't need to configure complex server nodes in every country, you just need to sort out the front-end shunt logic, and the rest of the network layer acceleration is all handed over to Google's backbone network.
Weld this set of highly available and low-latency golden defense lines to death in your cross-border sea-going business. From then on, whether you encounter malicious DDoS attacks by hackers or the volcanic eruption-level traffic peak during the first period of the Black 5. Network, your independent station can be as stable as Mount Tai on the public network and realize it smoothly.
