Also a post from 10 years ago, offering views on the technical points from the article "Some Experience and Lessons on .NET System Architecture Transformation".
The technical points from "Some Experience and Lessons on .NET System Architecture Transformation" regarding the CSDN transformation are as follows:
- Data layer: Abandon SQL Server databases and stored procedures, migrate entirely to MySQL databases on the Linux platform.
- Caching: No longer rely on .NET's built-in caching mechanisms; migrate to distributed Redis deployed on the Linux platform.
- Service-to-service calls: Avoid using .NET's proprietary protocols; switch to RESTful HTTP Web API calls.
- Static resource requests: Stop handling them with IIS; separate them to Nginx on the Linux platform.
- Filesystem access: Change to accessing a distributed filesystem on the Linux platform.
- Deploy .NET code on Windows servers behind LVS, using LVS for load balancing and failover.
1. Database: Should We Use SQL Server or MySQL?
As a web program, the front-end is never the bottleneck; the bottleneck is always the data end. Logically, .NET executes faster than PHP because .NET is compiled and PHP is interpreted. However, many large websites are currently deployed on PHP, mainly because PHP has more ready-made solutions.
If a system has issues, it's never the language's fault, but rather the architecture's, or the architect's problem. As a web service, most of the time the bottleneck is on the database. Some colleagues mentioned the expensive licensing cost of SQL Server. You can search for a talk by Dianping on qinfo; they used ASP.NET and MySQL. In essence, SQL Server and MySQL are both structured databases, and there isn't much difference for developers. Scalability of databases generally involves: 1) read/write separation, 2) horizontal partitioning by business, and 3) vertical partitioning of large tables. Everything else is just implementation details.
2. Cache: Use Built-in Cache or Distributed Cache?
CSDN migrated the cache to Redis. Personally, I don't think this is a problem with .NET's built-in caching mechanism. If you implement distributed caching, whether using Memcache or Redis, there will always be machines in between, so it will never be as fast as the web server's local cache. If the business volume is small, using a cache server to replace the web's own caching mechanism is actually not cost-effective. When system traffic reaches a certain level and the built-in caching can no longer meet the requirements, it becomes necessary to switch to a cache server. Of course, I don't think anyone would use a Windows server as a cache server. Whether it's .NET, Java, or PHP, is there any performance difference when using Memcache/Redis? The first system CSDN revamped should have been the blog system, which originally used the same system as Blog Garden's blog system, but after many modifications, it's no longer the original. It's hard to imagine how CSDN's blog, with such a huge user base, managed to survive with .NET's built-in cache. From the articles by CloudRoad on Blog Garden, we know that Blog Garden uses Memcached caching.
My understanding is that when the user base is small, you can use the web's built-in cache. When it reaches a certain scale and the built-in cache cannot handle the large amount of cached data, you need to switch to distributed caching components. The principle is to keep data as close to the user as possible. Many internet services now use Memcached or similar key-value databases to store all data in cache, while structured databases like MySQL are only used as backups, reading data from the database only when the cache expires.
3. System Protocol Selection
Microsoft is very fond of incorporating its own stuff into some protocols, and often only its own set of solutions can be used. For those who choose a full set of Microsoft products, it is indeed very convenient, but when we need to use non-Microsoft things, it becomes tricky. In web services, the main options are WebService or WCF's HTTP services. WebService is an open standard, a set of protocols based on XML format.
Web Service is a new technology that enables different applications running on different machines to exchange data or integrate without the need for additional, specialized third-party software or hardware. Applications that follow Web Service specifications can exchange data regardless of the languages, platforms, or internal protocols they use. Web Service is a self-describing, self-contained network module that can perform specific business functions. Web Service is also easy to deploy because it is based on common industry standards and existing technologies such as XML and HTTP. Web Service reduces the cost of application interfaces. Web Service provides a common mechanism for integrating business processes across the entire enterprise or even multiple organizations.
In web transmission, JSON is a shorter format than XML, and it is natively supported by JavaScript. There is also no shortage of third-party support. Choosing JSON as the carrier is better than XML. For me, RESTful is more of a data access style, making URL requests clearer, rather than a protocol. Therefore, in web systems, I prefer to use RESTful APIs with JSON as the carrier for APIs. If the entire system is full of Microsoft products, I believe WCF, being a Microsoft product, is still the best choice.
4. Filesystem Selection
Putting the file server on Linux is better than on Windows, at least Linux doesn't have to deal with file fragmentation. Well, I haven't worked with file services, so I can't comment much.
5. Static Resource Requests: IIS or Separate Processing?
We know that IIS can only handle static files. If accessing dynamic files like .aspx, IIS will pass the request to aspnet_isapi to handle, then return the result to IIS. For handling static files, Nginx has advantages over IIS. When dealing with static files, we usually merge and compress JS and CSS files, set up one or more separate second-level domains as image servers, and reduce the waiting time on the front end. Alternatively, we can hand over image services to providers like Upyun or Qiniu, which offer REST and form API interfaces for easy integration. They also provide CDN acceleration, which is cheaper than building your own static file server.
6. Load Balancing...
When the web server is insufficient for demand, you need to set up load balancing for the web servers. Of course, there are many ways to implement load balancing. I haven't deployed it myself, so I can't comment much. But when a single web server cannot support business needs, load balancing is a must.
Summary
Among the six points above, except for the second point—which I think shows the author's insufficient understanding of the system—I support the rest. When a system has problems, it's never the language's fault, but the architecture's. Of course, this is just my personal opinion. Perhaps everything I know is wrong.
Author: Zhang Wei Source: http://beixiu.net/