Internet business background
With this mobile Internet, cloud computing, big data, the development of networking technology, promote the healthy development of e-commerce, the Internet industry and Internet banking and other business areas. Whether Internet companies, or traditional industries, all business will be Internet-based, which is almost the only big brothers can be reached by consensus of all. So now the primary task facing us is to build and reform our system so that Internet-facing.
Several features of Internet applications:
Ø High Performance
Ø High Availability
Ø Big Data
Ø Low Cost
Internet Systems Design Principles
Process-oriented Internet technology, the system architecture should be designed in accordance with the following rules.
1.1 business architecture design principles
1.1.1 business platform
Ø business platform independent of each other, such as trading platform, payment platform, advertising platform.
Ø basic business sinking, reusable. For example, users, products, categories.
1.1.2 core business, non-core business separate
Ø core business system and separation of non-core business, streamline core business (destabilizing), diversification of non-core businesses. For example, as the main trading services, general trading services.
1.1.3 distinguish the main flow, with the flow
Ø distinguish which is the system main flow. Running, give priority to ensuring the mainstream process smoothly completed, auxiliary asynchronous background process oriented approach can be used. Avoid the main flow resulting in failure to roll back the primary process. For example, the next single, synchronous call snapshots, asynchronous notification ledger published.
1.1.4 isolate different types of business
Ø trading business transaction contract is signed between the buyer, the seller is required to ensure high availability, allows users to quickly place orders.
Ø Compliance business is not too high demands on availability, may give priority to ensuring consistency.
Ø spike demanding business of high concurrency, should be isolated with the ordinary business.
1.2 Application Architecture design principles
1.2.1 stability principle
Ø all a stability-oriented
Ø architecture as simple as possible, clear
Ø overly Design
1.2.2 Decoupling / Split
Ø variable partial separation of the stable portion
Ø core and non-core business operational separation
Ø separated from the main flow and the secondary flow
Application and data separation Ø
Ø separated from the service implementation details
1.2.3 abstraction
Ø Application abstraction: application depends only on the abstract service, the service does not rely on implementation details, location
Database abstraction Ø: application depends only logical database, the database does not need to care about the physical location and fragment
Ø server abstraction: application virtualization deployments, do not care about the physical machine configuration, dynamic allocation of resources
1.2.4 loosely coupled
Ø induction of cross-domain calls: as much as possible of asynchronous decoupling between different business domains.
Ø induction of non-core businesses as much as possible: the core, between the non-core business, try asynchronous decoupling
Ø The call must be synchronized, you need to set the timeout and the task queue length
1.2.5 fault-tolerant design
Ø Service Management: Service can be modified independently of each other, deploy, and release management. Avoid trigger a chain reaction
Ø cluster fault tolerance:
Ø fault-tolerant cluster: The cluster system, to avoid a single point
Ø Multi-room disaster: the deployment of multi-room, multi-live
1.3 Data architecture design principles
1.3.1 unified data view
Ø ensure data timeliness, consistency, accuracy, completeness
1.3.2 Data Application separation
Ø applications rely on logical database
Ø other applications can not directly access the host database can be accessed only by service
1.3.3 Heterogeneous Data
Ø source and target data content is the same, indexed heterogeneous. For example, commodity libraries in different dimensions
Ø content is not the same, do heterogeneous databases. For example, the order buyers and sellers Library Library
1.3.4 Data separate read and write
Ø access to large databases do separate read and write
Ø large amount of data in the database do sub-library sub-table
Ø different business domain database partitions do isolation
Ø important data configuration repository
1.3.5 rational use of cache
Ø When the database has the ability to support, as far as possible not to introduce cache
Ø rational use of cache to do disaster recovery
1.4 technical architecture design principles - principles runtime
1.4.1 can be monitored
RT Ø TPS and SLA compliance services
Ø occur if traffic exceeded expectations
1.4.2 application can be rolled back, the function can downgrade
Ø application when problems arise, the request can roll back to the previous version, or do function switch or downgrade.
1.4.3 Online Capacity Expansion
When Ø-than-expected traffic, online application system can choose the level of expansion
1.4.4 security guarantees
Ø ensure that the system of confidentiality and complete
Ø have sufficient anti-attack capability
1.4.5 fault-tolerant
Ø core applications required to live, to avoid a single point of design, and has its own fault tolerance and the ability to modify. TTR little downtime
1.4.6 Failover
Ø multi-room deployment, when a failure occurs, can instantly switch
1.5 technical architecture design principles - principles of deployment
Principle 1.5.1 N + 1
Ø Ensure that failure to take more than a system to avoid single-point problem.
Ø development and operation and maintenance functions separately. After completion of system development, operation and maintenance to the professional team management and operations.
1.5.2 DID principle
Ø 20 times the capacity design (Design)
Ø achieve three times the capacity (Implement)
Deployment Ø 1.5 times the capacity (the Deploy)
1.5.3 support the gray release
Ø new on-line system, required to support the "gray publish, step by step cut flow, fault rollback"
1.5.4 virtualization deployment
Ø virtual deployment: The system uses a virtual machine deployment, saving resources and management cost
1.5.5 Business subnet
Ø room service domain division deployed to: basic services and databases, the same service domain server deployed together; physically separated servers of different service domains
System upgrades selection rule
Typical of the architecture and technology of social networking applications to analyze the current social networking applications typically contain
architectural style are: micro-services, EDA, CQRS, front-end SPA, the system achieved through these architectural styles can be
scalable, highly available, and in the large users, under high concurrency and high performance, and the particular architectural style key
design constraints correspondence is as follows:
