1 large site system desirable characteristics
1.1 高并发，大流量
High concurrency, high flow: the need to confront high user concurrency, high flow access.
For example, there are 200 aircraft to Dubai tickets, but people are squeezed into the system to buy tickets 100w, 100w how to make this one can see real-time updates of the ticket, buy a ticket and smooth, is a website architects should consider the issue. This is perhaps unique visitors for one minute amount "two-eleven" 1000w of Taobao, is a negligible figure, but for the reputation of the site and the user experience, it is no small challenge.
1.2 高可用
High Availability: High concurrency is relative, not a high availability parameters have more regular, 7 * 24 is the dream of every site, but you do not know, at some point, he had no reason is down.
1.3 海量数据
Massive data: storing, managing vast amounts of data, you need to use a large number of servers. FaceBook weekly photos of close to 10 million did not support a large storage server, users believe the amount would not have been soaring.
1.4 用户分布广泛，网络情况复杂
The user is widely distributed, network complexity: Many large Internet services are provided to users worldwide, a wide range of user distribution, network conditions vary widely around. Interoperability between the various operators, data connections, and so each country.
1.5 安全环境恶劣
Poor security environment: Due to the open nature of the Internet, making the Internet more vulnerable to attack, including the various provinces card information is stolen and other events are common.
1.6 渐进式发展
Progressive development: Almost all of the major Internet sites are sites from a small start, developed a progressive, good Internet products are operating out slowly.
2 site architecture evolution
2.1 传统架构
Traditional project is divided into three-tier architecture, the business logic layer, database access layer, the control layer placed in a project, or SSM using SSH technology.
Advantages: suitable for individuals or small development teams, not suitable for large development teams.
2.2 分布式架构
According to business needs split into N sub-system, a plurality of subsystems cooperate to complete the communication between the communication technology using a remote RPC subsystem business process.
advantage:
- The split module, the communication using the interface, to reduce the coupling between modules.
- To split the project into several sub-projects, different teams responsible for different sub-projects.
- Just need to add a subproject increased functionality, call other system interfaces can be.
- The flexibility of distributed deployment.
There are advantages disadvantages, shortcomings are as follows:
- The interaction between the system require the use of remote communication, interface development increased workload.
- Each module has some general business logic can not be shared.
In order to solve the above disadvantages distributed architecture, we have introduced soa architecture, SOA: Service-Oriented Architecture Service Oriented Architecture of. The project is split into a service layer, presentation layer two projects. Service layer contains the business logic, you only need to provide services. Interaction, business logic and presentation layer only needs to handle all page calls Services layer to achieve.
2.3 SOA架构
SOA is a software architecture model, the common business logic extracted, encapsulated into a separate service.
Business system is decomposed into several components, so each component independently provide discrete, autonomous, reusable service capabilities can
be achieved through a combination of top business process orchestration and services.
Role: simplify maintenance and reduce overall risk, scalable and flexible.
2.4 微服务架构
Micro-service refers to the development of a single, small, but business services, each service has its own processing and light communication mechanism, can be deployed on a single server, so that professional people to do professional things.
Compared with the micro-services SOA, more lightweight.
2.5 SOA services and micro-architectural differences
OA mainly for enterprise-class architecture, using the ESB service (ESB enterprise service bus), very heavy, require serialization and de-serialization in XML transport format.
Micro-architecture major Internet services company, lightweight, compact, stand-alone, Http + Rest + JSON format based transport.
ESB can be said that traditional middleware technology and XML, Web services and other technologies combined with each other's products.
- In the micro-service, with different SOA, services can be operated independently of the other services and deployment, making it easier to deploy a new version of the regular service and the expansion of independent services for professional people to do professional things, rapid iteration of new products.
- In SOA service may share data storage, and micro service Each service has a separate data storage.
- SOA services and micro main difference is the size and scope, SOA is an idea, a service-oriented architecture system, micro-service inherits the advantages of SOA, ESB removal of the traditional message bus, using Http + json format of communication, more lightweight .
3 high concurrent design principles
System design needs to consider not only achieve business functions, but also to ensure that the system of high concurrency, high availability, high reliability and so on. Taking also into account the system capacity (flow rate, capacity, etc.), the SLA specified (throughput, response time, availability, downgrade, etc.), alarm monitoring (machine load, response time, availability, etc.), contingency plans (disaster recovery, degraded, limiting, isolation, cutting flow, roll back, etc.).
- Cache
- Asynchronous concurrent
- connection pool
- Thread Pool
- Expansion
- message queue
- Distributed Mission
3.1 split system
We make from scratch a new system when the system will first functional module architecture design, it is done directly perpendicular to the MVC system a large and using a war package release management, still need to be some rules by module split, or micro-designed SOA services system better? I believe that this project needs based on what kind of project requires human and material conditions and the amount of support the number of users and transaction volume basis. A good system should be designed to meet current needs and solve problems, to achieve control and schedule risk, forecasting and planning for the future, to avoid over-design, after the on-line version of a basic core, and then continue the iteration and improvement.
Today we talk about the conduct SOA, some dimensions and principles of micro-services architecture design module split.
- System dimensions: in accordance with the system function, split the business, such as, coupons, shopping cart, billing, order systems.
- Functional dimensions: the function of the system is doing fine-grained split, coupons, coupon system is divided into back-office systems, leading ticket system, ticket issuing system.
- Read and write dimensions: such as commodity system, if a greater amount of the query can be divided into two separate services, respectively, and a write service queries,
write characteristics split ratio; Read Multiple, consider multi-level cache; write more, can be considered sub-library sub-table. - AOP dimensions: according to access characteristics, in accordance with the AOP split, such as product details page can be divided into CDN, page rendering system, CDN is a system AOP
- Module dimensions: divide Web, Service, DAO on the overall structure of the code
3.2 Service of
In distributed systems, the interface to the business logic encapsulated into form, exposed to other system calls, then this could be interpreted as an interface called the service.
As more and more services and they will need to use the service of governance, it will be used Dubbo, SpringCloud service governance framework.
In-depth follow-up in Dubbo and SpringCloud mentioned in detail.
Services of evolution: in-process service - standalone remote service - clusters manually register the service - automatic registration and discovery services - packet service, quarantine, route - service governance.
Consider service group, isolation, current limiting, black and white lists, timeouts, retry mechanism, routing, fault compensation
Practice: load balancing, ZooKeeper, Consul and other automatic registration and discovery services use Nginx, HaProxy, LVS and so on.
3.3 Message Queuing
Messaging middleware is a client and server asynchronous communication framework, messaging middleware is divided into point and publish-subscribe communication, sending messages after producers, consumers may not need to wait for asynchronous accept the producer to send a message.
In the electricity supplier system uses asynchronous message queue push message, message failure problems noted retry idempotent.
Idempotence solutions to problems, the use of persistent global id + log records.
3.4 Caching
- Browser cache
- APP client cache
- CDN (Content Delivery Network) cache
- Cache access layer
- The application layer caching
- Distributed Cache
For data or abnormal data reveal all the details, you should not be allowed to cache, otherwise users will see these data in a very long time.
3.5 of concurrent
Serial to parallel changes.
4 high availability design principles
Achieve shunted through load balancing and reverse proxy.
From the avalanche disaster by limiting protection services.
Available through downgrade achieve some, to the detriment service.
Fault isolation by isolation.
By timeout and retry mechanism set reasonable request to avoid accumulation caused an avalanche.
Quick fix errors by version rollback mechanism.
4.1 Downgrade
For high-availability services, it is important to design a switch that downgrade, downgrade in the design of the switch, mainly based on the following ideas:
1. Switch Centralized management: by pushing the switch mechanism pushed to each application.
2. The downgrade of multi-level reading services: such as service call local cache downgraded to read-only, read-only distributed cache, the default read-only data downgraded (such as inventory stock status by default).
3. The switch of Pre: The architecture is Nginx-> tomcat, the switch can be prepended to the Nginx access layer, as switching in Nginx layer flow back to the source of the request or only a small rear end portion of the application flow back to the source.
4. Business Downgrade: When high concurrent incoming traffic, protect the user's system when the power designed to promote large orders, to pay the core requirements, and ensure data consistency to the final. So that we can put some synchronous calls into asynchronous calls, prioritize high-priority data or special characteristics, reasonable distribution of flow into the system to ensure the system is available.
4.2 limiting
Objective: To prevent malicious attacks or request exceeds system Peak
Practice:
malicious traffic only request access to the Cache
flow penetrating the back-end application processing using the Nginx limit
malicious use Nginx Deny IP policy or refuse to iptables
4.3 cut traffic
Objective: shield machine failure
practice:
the DNS: Domain Name Change inlet, may be added as DNSPOD alternate IP, IP normal fault, independent switches to an alternate address; slow to take effect practice
HttpDNS: precise scheduling of traffic to bypass carriers implemented LocalDNS
LVS / HaProxy / Nginx: removal of the failed node
4.4 can be rolled back
You can always fall back on a fast stable version released version fails
5 Business Design Principles
5.1 Anti-heavy design
Prevent duplicate page requests submitted, may be employed anti-replay key, put heavy table, Token other
graphical authentication to prevent attack machine.
5.2 idempotent design
Messaging middleware: messaging middleware should pay attention to the reasons due to network delays, leading to repeat the message consumer
third-party payment gateway: In the callback interface, it should be noted that the network delay, there is no time to return to a third party payment platform, pay attention to the callback power and other issues .
In a distributed system, to ensure that the order number idempotent uniqueness problems, Job execution timings generated.
5.3 Process Definition
Multiplexing workflow systems, to provide personalized service processes.
5.4 state and the state machine
Multiplexing workflow systems, to provide personalized service processes.
5.5 Background operation of the system may feedback
When designing back-office system, consider the effect of the preview can be feedback.
5.6 Approval of the background system
For some important back-office functions need to design approval flow, such as adjusting the price, and logging operations to ensure operational traceability, auditability.
5.7 Documentation Comments
The initial stages of system development should have a document library (design architecture, design, data dictionary / business processes, existing problems), fit the special needs of business code should have a comment.
Backup 5.8
Including backup codes and personnel. The main submit the code to the code warehouse management and backup, Repository at least should have multiple versions of the function. Personnel backup refers to a system should have at least two developers are aware of.
