: Full MP4 Video
Speaker: Dr. Xia.
1. Churyang's understanding
Startups need fast, multi-, good, and provincial technology architectures
- Fast: fast access to resources and services for business needs
- Many: Have a wealth of cloud services to choose, can not do their own do not do
- Good: emphasis on extensibility and high availability, do not have to be "money" at the beginning of the binding, but also need a good user experience (can use is the most basic user needs)
- Province: Can be elastically scaled, and pay on demand is the best savings
Whether it is a start-up or a traditional enterprise, many architectural ideas are interlinked: OS, front end, backend, database, framework, etc., according to their own needs to choose. The next thing to do is to find the corresponding service function in the cloud.
7 Design principles for cloud application architectures
- Consider any system to be ineffective at design time
- Loosely coupled and stateless design (only stateless applications can be used for faster scaling)
- Design for scalability and Autoscale
- Safety throughout the design always, in each layer
- Do not worry too much about constraints and failures (such as the ability to deal with each time is not enough, to do is clear understanding of the current design ideas, because the cloud is infinitely extensible, so do one thing after the cloud can be replicated and expand the ability)
- Multi-factor parallel distributed processing
- Full use of different services
Startups can incrementally use cloud services in the following ways.
- by Business life cycle approach : Get familiar with the operation from the test to the subsequent production deployment, and gradually get used to the cloud service
- according to the application scale change method : Start with a EC2 instance, then introduce the static data separation, relational database expansion, cache and so on according to the business development, and gradually understand more cloud services
- by Business need method : Start with IaaS services such as basic compute/storage/network, and gradually put energy into business innovation by using PAAs services directly based on business, such as Message Queuing, full-text search, mail sending, etc.
2. The business and technical requirements of the start-up company
- Quickly validate product Services
- Race Against the window of opportunity (Internet 1 years equals tradition 7 years, year of the dog)
- The small technical team has no historical baggage
- Focus on providing solutions to solve problems
- Avoid engineering chatty and rework
- Avoiding risk and preparing for high-speed growth
3. Technology selection for start-up companies 3.1. Common technology stacks
- Operating system: Linux:centos,redhat,suse,ubuntu
- Mobile: IOS, ANDROID;HTML5
- Website Front end: php/asp/jsp, Html/css
- Front-end Frame: Flex,jquery,sencha
- Development tools: Eclipse,svn,sdk/ide
- Technical framework: Struts,springs,hibernate;velocity;ruby on Rails
- Development language: Java,php,python,ruby,net,node.js,go
- Load balancing: Software: nginx,squid; hardware: F5,citrix Netscaler
- Database: Rdb:mysql;nosql:mangodb
- Cache: Memcached, Redis
- Content Published: Cdn,dns
- Other: Lucene (full-Text Search tool)
3.2. Architectural Considerations
- Performance
- Highly Available
- Scalability
- Support high-speed growth of customer, business, access, and data
- Difficult to plan and grow without limits
- Performance cannot be affected when scaling
- Seamless: Just a smooth increase in resources
- Efficient: maintenance of low cost per user
- Security
- Easy to manage
- Cost controllable
- Fast Delivery
3.3. Solutions for AWS Services
- Agile, fast, flexible
- Low start-up costs, on-demand pay-per-use
- No longer need to guess capacity
- Focus on innovation
- Get rid of the non-differentiated physical activity
- Can be deployed in a few minutes globally
- Lower IT overall cost
3.4.7 Recommended Principles for cloud architecture design
- Consider any system to be ineffective at design time
- Loosely coupled and stateless design (only stateless applications can be used for faster scaling)
- Design for scalability and Autoscale
- Safety throughout the design always, in each layer
- Do not worry too much about constraints and failures (such as the ability to deal with each time is not enough, to do is clear understanding of the current design ideas, because the cloud is infinitely extensible, so do one thing after the cloud can be replicated and expand the ability)
- Multi-factor parallel distributed processing
- Full use of different services
4. Six days to complete the technical architecture design of the start-up company 4.1. The 1th day, development and private testing
First server (start a VM from the cloud)
- Test with EC2 instances in the cloud (running Apache, MySQL, etc.)
- You can deploy multiple units to divide roles, since just opening, start with 1 VMs first
- Bind the IP address to the server (limit: 5 Elastic IP addresses per account)
- Set the DNS domain name to point to the elastic IP
4.2.2nd day, launch and public beta
To test, the original VM is not enough, need a larger service
- Increase block storage capacity (EBS)
- Use the correct virtual machine type (such as CPU core, memory, GPU card, hard disk read and write speed, etc.)
- Change virtual machine Size on demand
- Understand the long-term, permanent, transitional (goal is to understand the various operations, limitations, and performance scenarios in AWS)
- There's no fault-tolerant design
Separate site applications and data tiers
- More capacity
- Each layer is expanded separately
- Fine tune the instance of each layer
- Focus on safety
- Using firewalls
- Database As for VPC private subnets
How do I select a database? SQL or NoSQL?
Why is a relational database commonly used?
- SQL is very mature and feature rich
- Many of the ready-made code, tools, and knowledge
- Extending the design idea to make the hair feasible
- For example, for frequently-read apps, read-write separations are used
- Reality: The future will gradually use multiple databases
- Some workloads use NoSQL more appropriately
- Choose the right tool for each job
Experience Sharing: relational databases are complex
- relational database for high scalability, management is often difficult to operate
- Poorly managed relational databases can cause: data mismatches and why IT systems are down offline
- Small for start-up teams, less part-time, especially
AWS provides a managed relational database
MySQL, Aurora, PostgreSQL, Oracle, SQL Server
How to further improve efficiency?
4.3.3rd day, customer on-line
High availability is placed on top of the table
- The 2nd day is: Dynamic content in the EC2 instance, static into the S3, with CloudFront acceleration, with RDS hosting the database, and with Elasitccache cache
- Today, on the 2nd day basis, create EC2 in another AZ (availability zone) to save dynamic content and jump with Elb load balancer
- Elb is a managed load balancing service
- Fault tolerant
- Health Check
- Distributed across multiple availability zones
- Elasticity-Automatically expands capacity
- Turn on RDS Muti-az so that RDS is highly available
- Create an instance of Elasticcache in another AZ (availability zone)
User session issues with users access
- Issue: Status is usually stored on local disk (no sharing)
- Simple solution: ELB session stickiness (Session binding)
- Better scenario: DynamoDB (Save session state in a NoSQL database)
- Dynamodb is a managed file and Key-value storage
- Easy to start, easy to expand
- To millions of IOPS
- Read and Write
- Consistent, fast performance
- Durability: Ideal for storing session data
4.4.4th day, let us viral growth
Goal: Use elastic it instead of guessing compute capacity
Use auto-zoom capability (Three musketeers: CW, as, ELB)
/soa of micro-service
Decompose applications into small, functionally single, loosely coupled, stateless building blocks
- Save temporary data on the instance store only
- As long as data that exceeds a single HTTP call is persisted, and then stored
- This allows for elastic scaling on demand.
- This structure is simple, but you still need to
- Configure specific parameters
- Deploy code to multiple instances
- Manage development Test production multiple environments (Dev,test,prod)
- Maintain multiple versions of your app
Solution: Use elastic Beanstalk
- Three-tier web, application, database architecture that is easy to deploy, monitor, and scale
- Infrastructure managed and deployed by Beanstalk
- Customers remain in control
- Pre-configured app container
- Easy Configuration Change
- Supports the following platforms
If the system is more complex, you can use SQS to implement loosely coupled
- To deploy a task to the queue service
- SQS provides buffering through the team as a back-end system
- Asynchronous processing-Grasp the rhythm yourself
- Remove delay for critical path
4.5.5th day, add more features
AWS has more services, and you can choose as many as you want
AWS Services for highly scalable and highly scalable services
| itself can be extended and highly available | Scalable
and highly available with the right architecture |
| Elasticloadbalancing |
EC2 (not highly available by itself, but once deployed in multiple AZ, a highly available architecture can be implemented) |
| CloudFront |
Vpc |
| Route53 |
|
| S3 |
|
| Sqs |
|
| Ses |
|
| CloudSearch |
|
| Lambda |
|
| ... |
|
Keep an eye on innovation as you expand your team
4.6. On the 6th day, continue to grow rapidly
The data is too large to extend the relational database
Enhance RDS Instances
- A large instance type
- More Storage/More IOPS
- Read replica read Replca (master master-from Slave)
- Scale to the compute capacity of a single DB instance
- Applies to RDS for MySQL, PostgreSQL, and Aurora
- "Write" = Master Master
- Replication has a delay
- "Read" and read-only copy (from) read Replca (slave) that can tolerate outdated data
- High-consistency "read" = Master Master
If you need to write often?
- Challenge: Sooner or later you will reach the limit of the master node's write operation or storage
- Scenario 1: Federated Fedration (based on data functions on multiple databases)
- Divide a database table into smaller, self-supporting databases
- Cross functional function queries are difficult
- Little help for a single larger function, table
- Scenario 2: Shard Sharding (a set of data is on multiple hosts)
- Storing subsets of rows in a database shard (Big Data domain is very common)
- More complex application levels
- There is virtually no limit to extensibility
- Complexity of operations
Another solution, NoSQL data storage-dynamodb
- Sacrifice the query and performance of the relational database to get
- More flexible data models
- Ability to predict performance with horizontal scaling
- Can scale seamlessly
- Distributed systems can be extended for both read and write
- Slice + Copy
- Automatic partitioning
- Data size Increase
- Increase preset capacity
5. Summary
Architecture with no maximum user count
- Automatic scaling at the application level
- Multi-AZ Deployment at the data plane
- Using the cache
- relational database with read-write separation, cross-region deployment
- Using S3 to save dynamic content
- Using DYNAMODB to save unstructured data
- SNS, SQS, cloudsearch to solve business needs
- ...
Startup AWS Architecture Principles
- Stay concise and stateless
- Multi-use managed Autoscale services
- Placing an EC2 instance within an Autoscale group in a multi-AZ
- Select the appropriate database type
- Skillfully use caching at multiple levels
- Automating deployment with Administrative tools
"Summary" startups build high-scalability architectures with AWS
