On InfoQ, I saw the introduction video of Alipay architecture: http://www.infoq.com/cn/presentations/alipay-elastic-computing-architecture
I feel deeply that most of the previous system architectures only achieve service-oriented architecture, and there is still a lot of work to be done in terms of elastic architecture, high availability, etc. in combination with the situation of my company, I think the following points can be used for reference and consideration:
1) call between systems: Alipay uses a registry to unify the call between services, which is similar to Taobao's HSFhttp://wenku.baidu.com/view/c8e045f39e31433239689393.html (ALI also has a framework called Dubbohttp://code.alibabatech.com/wiki/ display/dubbo/Home-zh, which is a centralization structure, which is better and more difficult to say). , individuals prefer the way of registration center, because it is more convenient in management. As for the problem of single point failure, because the function of registration center is relatively simple, it can basically ensure high availability), I think the system calls need to do the following: Transparency: the caller of a service does not need to know which node the callee is deployed on. Traceability: it is convenient to find which services a node depends on and which services it is dependent on. It is necessary to avoid single point failure and use a unified framework to realize inter system calls.
2) Use framework to realize distributed transaction: there are many scenarios in transaction system (many other systems should have similar requirements), that is, after database splitting (even some tasks are not performed by database operation), it is necessary to realize the consistency of each sub task. It is a good scheme to use framework to realize it
3) Distributed locks: additional services are provided to support distributed locks and avoid database selection for update. This can greatly reduce the pressure on the database
4) The inter system calls include database transactions, setting a relatively short time-out to avoid large-scale time-out due to the unavailability of some systems, occupying thread resources, database connection resources, etc., which leads to system crash;
5) Elegant degradation of services: This is also related to No.1. The system dependency is divided into strong dependency and weak dependency. When system degradation is required, some weak dependency service calls will be cut off to ensure the normal execution of main services;
6) Good monitoring system: find problems as soon as possible;
7) failover: what was odd before was why the same bank payment problem was wrong, and the corresponding banks on our payment gateway could not pay, but Alipay could do it because Alipay could automatically switch to other available channels of the bank after detecting the failure.
There are other places to learn from, such as customizing containers and expanding containers. However, such a thing is not a large company, and it is difficult to do.
Share to:
- 2013-05-03 11:56
- Browse 4076
- Commentary (0)
- Classification: Enterprise Architecture
- View more