Web Architect's capabilities (RPM)

Wen/Liu Ruhong

Recently and a few friends talked about the popular web 2.0, also mentioned the most important role-architect. There are disputes between the parties, only because of the background and perspective, including the word architecture, itself from the architectural reference, as for the architect, you can simply from the architect of architecture to extend, is nothing more than design structure, design a building structure. Back to the software itself, it can simply be understood as the person responsible for designing the software framework.

We have not discussed the key to the seemingly identical but differentiated roles of architects, software architects, system architects, and their web architects, and it is not clear that they will be able to be benevolent see by 1:30, and finally we discuss some of the basic knowledge and capabilities that a Web 2.0 site architect needs, Since it is a personal opinion, it is inevitably biased:

Be familiar with your business model and target group

This is the most important, Web 2.0 is essentially a Web-based business application, if you do not really understand your business, do not understand the user's core needs, do not understand the typical behavior of your target customers, it is difficult to do the site. From this perspective, a Web architect must first be an excellent product manager. Most of the time, we just do business technology leadership is enough, blindly pursuing the advanced technology will be mired in the mire.

Finding a balance between technology and business means having to understand the competitiveness of the core of the business as a whole. What are the basic demands of the target population? Then choose the lowest-cost technology to meet your business needs, but in turn, you must retain the appropriate platform space for your business development.

For example, if it is a photo-sharing for the purpose of the application, you can write the registration program is a bit rotten (but can not be rotten to not move), you can help the system do not look so good, but upload photos and browse photos absolutely not slow, you can not design the database so well, but the storage problem must be cautious , absolutely not able to more than 10,000 photos, the site speed and cattle general ...

Only when you really understand what you're going to do, technology can get cute.

Understanding Load balancing Policy implementation

Anyway 2.0, what kind of business you have to make a key assumption: your traffic is bound to rise, a single machine must not be able to meet the needs of your business development. I believe this assumption is reasonable and no Web 2.0 company believes they can use a machine to change the world.

It is not a requirement to design an idealized load-balancing strategy from the outset, which is a bit of a "rainy day", but as a web architect, make sure you leave some room for "separation". Therefore, it is necessary to properly understand the implementation of load balancing policies at different levels.

In general, in the early stages of small-scale development, proper consideration of database unbundling and separation of domain names by business is sufficient. In a medium-sized situation, it may be appropriate to adopt hardware or software load-balancer, where load balancing at the Web level can be done with hardware like f5/netware, and of course, Apache or more specialized load balancing software, such as NLB under Windows and LVS under Linux. In order to achieve load balancing, it is also necessary to make some appropriate adjustments at the application server level, at least not at this time to allow you to use the session variable at will (in fact it is not completely unusable), and once you have a cache (Web 2.0 who does not know memcached?), If not considered thoughtful, originally a single-machine environment good application in the end will become a mess, essentially nothing is the problem of data synchronization, in fact, you think, you put the flow and pressure decomposition, data fragmented, no problem is no justice.

As a Web architect, it is important to understand the different implementations of the load balancing strategy, and to understand the problems and key points that may arise after load balancing, which is not justified in face.

Design "reasonable" storage

No one is going to store everything in a relational database, and no one can say that a Web 2.0 site with a relational database can solve the problem. If Web 2.0 is user-centric, it can also be said to be based on user data as the core value, the core driver of the application is data. There is no way to discuss whether you should use a relational database or a relational database, and many things find a balance in it, a "reasonable" balance.

Traditional storage can be divided into Sans, NAS, and Das, but with the development of technology, the boundaries of which are increasingly blurred, fuzzy can even let you forget the differences, you can look at the money in the pocket, roughly understand how much silver can do many things. But you still need to choose, for Web applications, most of them are PC servers, and many people may be keen to build storage architectures like GFS with relatively inexpensive devices.

Many people think that Web 2.0 is the most critical business, "Money can solve the problem is not a problem," This is true, in the early days if the architecture is designed to the next 5-10 years of architecture, the architect of this "vision" must become a future laughingstock, but in turn not to consider any data distribution possibilities, So sighted will eventually take the consequences.

Then look at the actual situation, how should the architect face it? In the start-up phase, a simple and straightforward relational database is available, and you don't have to spend too much time thinking about it, as long as you roughly calculate the capacity of a server, and then estimate how much you can do to get around half the capacity limit, that's enough. Simply put, rude, a file server, a database server, as long as do not make stupid mistakes, such as a file only a directory, completely non-split, such as the database only a table, coupled with too much logic and so on, since there is no, then let go. And in the business to a certain scale, such as already have 100,000 users, regardless of your storage is impossible, at this time we will find that many performance problems are due to less reasonable storage problems, this time storage design is more to deal with the performance of the consideration. In the development to a larger scale, storage manageability and cost issues have gradually become critical.

It is particularly important for architects to choose different design strategies at different times, without the best, only reasonable architecture, and storage.

Integration capabilities of heterogeneous platforms

If from an enterprise application point of view, absolutely do not agree with a system has more than one platform, it will needlessly increase the cost of integration, the past "Data Island" is the best proof. So is it good enough for a web architect to be on a platform, or can it drift between multiple platforms?

We have to redefine the meaning of the "platform", I simply understand it as two levels, one is the operating system level, one is to develop a language level, of course, the problem is big, can say the framework, can say the database, can say the agreement and so on. But one thing to be sure is that the operating system is the foundation of your business software, and the development language is the tool to implement the business, and the combination of the two, there are some classic architectures recommended, the. NET aspect is Windows 2000+sql Server +iis 6.0, and then through the visual Studio 2005/2008, based on Microsoft, fully use the services they provide, LAMP is linux+apache+mysql+php, the Java EE Web architecture is generally accepted as hibernate+spring+struts, as for Ror, This is the star-style comer.

It's foolish for a web architect to think about which platform is good or bad, but to be proficient in a platform that will be handy when you're dealing with a business, but it's better to be familiar with another platform, although we can say that the times have changed, all XML, all standard rest calls, But can you really guarantee it? Most applications are. NET write, need to provide a forum, you use the discuz, you need to properly modify the business, although the forum itself is very powerful customization, but to embed a specific business, not to be ignorant of lamp, so even the unified login problem is not solved, of course, You can also say that I don't need it, because there is something else to choose from, but one thing is the fact that you can't add the modules that best suit your business according to your business needs.

In my personal understanding, a good architect can preferably be familiar with two operating systems at the same time, more than two development languages, one aspect is the real world business complexity, one aspect is that since there will be different platforms, it must have its rationality, to win the family's long, can help an architect on his work platform more rational , just look at the problem itself, in fact, in turn see. NET, Java or PHP, is not to learn from each other its merits.

A good architect should have the ability to deal with heterogeneous platforms, and it must be remembered that the Web itself is heterogeneous.

Design for better interaction

When it comes to interaction, most people think of the interactive design of the product design category, and Web 2.0 emphasizes user-centric, interactive and user-driven interaction design. But what I'm talking about here is more of a general sense of front-end design, or "presentation-layer architecture."

We all know that Web 2.0 attaches great importance to interaction, and because of this, most engineers spend more time not in the background of data processing, but in front of the interaction. Today, in Ajax and RIA, one of the most important responsibilities of a WEB architect is to simplify the development complexity that results from "high interaction."

We talk about Ajax, but not every developer to manipulate XMLHttpRequest, not to let everyone understand the HTML DOM, JavaScript and CSS, and then the combination of the dazzling, everyone will know, so that many developers are vomiting blood is not the background code debugging, It's JavaScript and CSS, because it takes patience and skill. and the role of architecture is to define effective norms and implementations.

To put it simply, developers are going to pop up a Facebook-like box that doesn't make every developer recount, and then racking their brains to be compatible with different browsers, compatible versions, and then compatible with different pages. I need to fetch the data from the background, need each developer to write their own, need a hidden effect, also need recount.

So, some people will say that the above questions jquery can be solved, there are developers will use this kind of library, but there will be people with prototype, and the architect's responsibility is to specify what should be used, how to use, which is not available.

I can simply understand that the key role of the interaction architect at this level is to define whether to use jquery, what kind of HTML should be used for different interfaces, what server interface technology should be used, and what remoting framework should be used.

The goal of defining these interaction technologies is to achieve the best possible interaction in the simplest possible way, which is where the architecture is responsible.

Performance and fault diagnosis

Should not be included in this issue, but considering the typical Web 2.0 is always beta version, in other words, the problem will always exist, you can not start to make a perfect application, as the business grows, performance problems and system failures are unavoidable, the scene is very common, Traffic up, but found that the overall site becomes extremely slow, some pages intermittently error, more deadly is that the developers themselves have also carried out code review, but still did not find "stupid" error.

A good architect should be able to help with some diagnostic and optimization, business-based, technical judgments at this time, and find the core problem in an increasingly complex system. Generally speaking, the performance of an application system is related to the level of SQL, but in the end what SQL has a problem, the extent of the impact of the problem.

I'm not quite in favor of hindsight, but a good web architect should be able to gain insight into the performance-led problem, as well as a set of proven troubleshooting scenarios, whether the database is a program or a network, an operating system or a hardware problem, or both.

Performance and fault diagnosis involves too many layers of operating systems, databases, configuration files, program code, and even network-related, each of which needs to be illustrated with a book, perhaps not enough. But as architects, it has to be felt.

This is my personal understanding of the needs of the Web 2.0 architect, but I think there are many aspects of the ability is needed, such as the ability to communicate, abstract ability, the ability to balance and so on, I hope you can help to add.

Author Profile:

Liu Ruhong, a technology director and co-founder of the company, has more than 7 years of experience in. NET development and is familiar with large-scale system architecture design on various platforms. He is the ". NET component design, Second Edition" (programming. NET components,2nd Edition) translator.

(This article was selected from the June 2008 issue of the programmer)

Web Architect's capabilities (RPM)