"Summarizing" the MicroServices (microservices) architecture in an AWS cloud computing environment

Source: Internet
Author: User
Tags docker hub dynamodb aws elastic beanstalk

: Download the full MP4 file

1. Churyang Summary
    • Micro-service is not a stone crack inside, is based on similar SOA, Blackboard, C/S and other application architectures based on the integration of Agile development, devops and other concepts based on the development of
    • The advantages of microservices compared to traditional applications (rapid deployment, de-center, good isolation, etc.), and many disadvantages (more complex, communication loss, high testing costs)
    • MicroServices are not just a new approach to application design, but organizations that use this architecture may also need to make appropriate adjustments
    • AWS has designed ECS (EC2-based container service), lambda (event-driven computing platform) for microservices, and developers can simply write JavaScript or Java logic, and Lambda is responsible for performing work, like HPC execution mode.
    • The original AWS Elasticbeanstalk had already been delivered to the application environment using Docker at the bottom, with only a few more qualifiers (requiring language platforms such as Java, PHP,. NET, etc.) and ECS did not have so many requirements. EB is like Gae and ECS is more EC2
2. About MicroServices (microservices) 2.1 Why micro-services are needed

The original 3-tier application architecture (presentation layer, logic layer, persistence layer – data layer) each large-scale application has a lot of logic to wrap, so it is very time-consuming to develop, maintain and manage, and due to the long development cycle, there is a risk of lagging demand

The development model of micro-services is different, it is the idea is to each large-scale application, decomposition again, each relatively independent of the small module into a separate program (so-called a small service) each service is run independently in the process, independent deployment, each service through a lightweight way to interact, such as HTTP Api. Different services can be developed in different languages, and the data storage mechanism is preserved. This enables agile development and maintenance of applications with a very short time period

2.2 Why is MicroServices appearing?

The complexity of technology development, the cost of development time, the risks borne by the environment, the associated concepts and the results of development ideas (such as agile development)

MicroServices are based on historically existing, popular programming architectures, rather than in stone seams, which include:

    • Blackboard Architecture : The idea behind a series of independent programs working together to work with the same data structure
    • client/server Architecture : Client and server architecture. It is the software system architecture, through which can take full advantage of the hardware environment of both ends, the task is reasonably distributed to the client side and server side to achieve
    • Component Based Architecture: With the support of the Component Object model, by reusing existing artifacts, software developers can "plug and play" to quickly construct application software
    • peer-to-peer Architecture: Unlike the master-slave architecture, each user or program entity on the network has the same level, and plays the role of the client and the server.
    • Service oriented architecture: The famous SOA architecture is the way to construct distributed computing applications. It sends application functionality as a service to end users or other services.

On the other hand, microservices not only inherit a variety of application architectures, but are also influenced by ideas in many areas of software design, such as:

    • Domain Design driven (analysis of modeled complex operations)
    • Agile methods (increase efficiency and reduce waste)
    • Continuous delivery (faster, more reliable, more frequent deployment of applications)
    • Virtualization and IaaS (simplifying the infrastructure environment)
    • DevOps (more compact for your team)
2.3 Characteristics of micro-service
    • Small : Each service only do one thing, and the goal is to do things well, to do the ultimate. For example, some people in the industry are even measured in code sizes (for example, 100 lines, 1000 lines of code).
    • running in a separate process : different services can run on different hosts
    • Lightweight communication mechanism : refers to between services and services, through a lightweight communication mechanism to communicate (light, refers to the communication with the language and platform-independent, such as JSON, XML, etc.). Instead of traditional heavyweight communication mechanisms such as (. NET Remoting or Java RMI)
    • Loose coupling : No need to change dependencies, just change the current service itself and deploy it independently. This means that the service is deployed and run, and the other services are presented in an independent posture
2.4 Advantages and disadvantages of micro services

Advantages:

    • good isolation and availability , scenario: Failure of one service without affecting other unrelated services
    • The speed of independent delivery is greatly improved , the scenario: the ongoing deployment and ongoing development of the emphasis now requires a high rate of delivery, microservices can do. The delivery speed of the traditional monolithic integration application deployment is very difficult, and the requirements for infrastructure, environment and application testing are very difficult.
    • Centralized management , scenarios: Deploying a packaged application, a key core application, is a central point when managing the deployment of traditional applications. MicroServices does not have a center, so teams can deploy independently, DevOps, and mitigate risk during operations

Disadvantages:

    • complexity , Microservice is inherently distributed, and the complexity of the distributed system itself requires the experience of developing, testing, and operations personnel to handle complex systems.
    • the operational overhead of the service , microservice because there are many services, compared to the traditional architecture has a lot of inter-service communication overhead, so less efficient than the traditional monolithic. and generally need to follow devops to manage patterns and processes.
    • the problem after the service interface does not match ? Although the Microservice uses a standardized interface, there is an uncontrollable risk of a service version losing control or communication with other services due to the existence of a version of the interface with many services and different services.
    • test , which requires an entire ecosystem test compared to a traditional application architecture, and therefore the overall test time is longer and more complex
    • the number of fan-shaped increases is mainly due to the significant increase in data traffic as services increase
3. Micro-Service Design 3.1 Conway Law Conway's laws (Application architecture requirements for organizational structure)

The organization of any design system ... Will inevitably produce the following design results, that is, its structure is the portrayal of the organization's communication structure

--Translation--
What kind of organizational structure, what kind of software products. Using traditional organizational structures to develop microservice is going to be a problem.

3.2 Traditional application organization structure (SILOS)


Enterprise Application Architecture as follows:
-Product Team
-User interaction Experience
-Development Team
-Test team
-Database Team
-System Management
-Network Management
-Storage Management, etc.

It is good to use this mode for traditional application architectures with integrated (Monolithic) applications, but microservice use of this architecture can be problematic (since each service may have a need to match such a team), and this organizational structure The cost of information communication between teams is very large

3.3 For Microservice, organizations need to make adjustments (DEVOPS)

Adjustment method: Set up agile small and efficient teams for each service of Microservice, each small team is responsible for each services (throughout the entire application's various service modules), independently carry out corresponding development and management work


Microservice's architecture is closely related to DevOps, Microservice is the evolutionary result of DevOps thinking, and DevOps is the best tool for Microservice

3.4 How to design smaller (real small) service

Recommend a book: Building microservice

    • Purchase Address: Amazon's books
    • Book Review Address: https://book.douban.com/subject/25881698/

Summarize the key points for small services:

    • Each service should focus on the "business" area and each service solves a specific problem
    • Structurally "loose, coupled" architecture for post-deployment, testing, debugging
    • The "bounded" context, which does not require the surrounding parts of each service-other services, dependent services, etc., the team focuses only on the service itself and the API of the service; Traditional application requirements need to be understood and designed to be developed, and microservices can be started faster by the team
    • Each service can be deployed independently
    • Tools to match ideas (such as devops tools, etc.)
    • Encourage the use of new technologies (recommendation: Bostal rules, be conservative when doing, open when accepted)
    • The culture of automation
    • Something that can be rewritten within two weeks (measure Microservice's small standard of service)
    • Two pizza teams (Amazon internal Idea, a nimble and agile team should be in control of about 10 people)

3.5 Microservice's practice-Netflix IPC Stack


★netflix IPC Stack 1.0
One application within Netflix, 1.0 uses traditional silos-style applications that do not conform to the Microservice design style


★netflix IPC Stack 2.0
Netflix started with an abstraction of coarse services in the IPC Stack 2.0 and deployed independently in containers that are isolated from each other, interacting with the HTTP API

4. Microservice related technologies and cloud Services 4.1 container Computing technology

Traditional virtual machines (owning hypervisor) can have performance losses, while Docker uses LXC technology to remove hypervisor and directly use Linux Kernel for improved performance. This rapid deployment and management capability of Docker coincides with the rapid deployment of microservice services.

There are 3 modes of Docker running on AWS 4.2
    1. EC2 (use Docker directly with the Docker-capable AMI launch instance in the EC2 service)
    2. AWS Elastic BeanStalk (packaged with Docker technology to automatically deploy managed class applications for resilient Web applications and service architectures to support the language environment of PHP, Java,. NET, etc.)
    3. EC2 Container Service (provides visual, pipelined management capabilities for Docker containers)
4.3 EC2 Container Service

Key components of ECS

1. Cluster (Container Cluster)
-Differentiate regions
-equivalent to a resource pool
-Equivalent to grouping container instances
-Empty at startup, dynamic expansion and adjustment

2. Container instance (EC2 instance running container)
-a EC2 instance is included
-There is a Docker process in the instance
-An ECS agent exists in the instance (the agent is open source, developed with Golang)

3, Task (is a Docker container)
-Multiple tasks can be set per instance
-The task is the unit of the job
-Allow tasks to group and set associations
-The task runs in the EC2 instance

4. Task definition
-Define tasks with JSON
-Includes: Docker hub template, number of CPUs, memory, etc.

Task scheduling (Implementation of compute resource management)
-long-running service (long-running services)
-Perform tasks in bulk (RunTask for Bach jobs)
-Integrated Third party scheduler schedulers

4.4 Microservice Practice-Coursera (using ECS) 4.4.11 MOOC Sites

4.4.2 Coursera's needs

Prior to Coursera developed a set of traditional Internet application architecture, there are many program units, and each unit has a lot of services (coarse granularity), the main requirement is

    • Reliability: Because there are more people in the service, the company's reputation is 2 if the application goes down. Big impact
    • Easier to develop: Internet company survival pressure, need to go online more applications to meet customer needs, on the other hand, small and formulaic development model is necessary
    • Deploy faster
    • Cost considerations: Hope for higher input-output ratio
    • More efficient operations: only 1 operations personnel, the existing environment is too complex to maintain
4.4.3 Coursera's Choice route

Coursera tried a lot of methods, and finally did not want to carry out their own and toss, so chose the ECS
1. Your existing technology
-Tried, but not reliable
-Difficult to operate

2.MESOS
-Very powerful, poor ease of use during actual operation
-DevOps teams that need to be matched all the time

3.Kubernetes
-Good performance on GCE, not elsewhere (and GCE is a PAAs that needs to be tuned for user applications, with a learning cost)

4. Using ECS
-Nearly 0 maintenance costs
-Coursera has used AWS services, such as IAM, to continue
-Better understanding and operation of developers (Docker itself or host without changing language development), low learning costs

4.4.4 Final Coursera modified Microservice architecture
    • A large number of work deployments using ECS Microservice service in the
    • Front-end + Scheduler design
      • Generated requests (through API calls or internal communication via scheduler)
      • New requests are saved in the SQS queue
      • Processing requests based on status from other services
    • Back-end design
      • Attempt to run task via ECS API (not through interface, faster and more timely)
      • If the task fails, the task is automatically rolled back to the queue and then retried
      • Keep track of task status and update Cassandra database (a NoSQL database)

4.5 AWS Lambda (managed, event-driven architecture compute Platform service)

Characteristics:

    • 0 Management: is a computing platform rather than a Windows or Linux, so do not need too much to manage the environment related things (such as how much CPU, memory, bandwidth, etc.)
    • Event-driven: generating automatic calls to blocks of code based on events
    • Computing platform: For developers, it's a computing platform that submits code and waits for results
    • Users can focus on business logic rather than infrastructure: the user develops service for the business (JavaScript, Java, etc.) and sets the trigger mechanism for uploading code, while AWS Lambda is responsible for subsequent work such as capacity, scaling, deployment, fault tolerance, monitoring, logging, etc.
    • Automation extensions: Users only pay for the costs they use, not over/under provisioning
    • Fine-grained pricing: The price measurement Unit is milliseconds (in 100ms) for short time tasks very valuable, no minimum consumption, can be free trial
    • Events occur in different shapes and sizes: S3 event notifications, DynamoDB streams events, Kinesis (event flow) events, custom events
    • Synchronous asynchronous is callable: Synchronous Asynchronous Pattern calls can be selected for different business scenarios, such as when some application logs produce problems after an asynchronous response triggers a lambda call. Or custom practice occurs after a synchronous triggering of a lambda call

Scalability and utilization of the infrastructure

Types of resources Scalability Utilization
Enterprise-owned IDC Week level Low
Amazon EC2 Minute level High
Container Seconds Higher
AWS Lambda Milliseconds Highest
4.6 Microservice Practice-aws Lambda Use Method Example 4.6.11 Content Management Systems (CMS)

Specific requirements include:
-Allow users to upload avatars
-You need to save the picture
-Need to make thumbnails for avatar, use in different web locations

4.6.2 Traditional situation
    • A CMS application that does all the work involved in the process includes: upload avatar → save picture → create thumbnail image

    • modifying any link in a traditional situation (such as saving a picture) requires that the CMS system be repackaged and then updated

4.6.2 Lambda Transformation situation
    • Users upload images into S3, a new S3 object will trigger a lambda function to convert to thumbnails, save thumbnails to another bucket in S3
    • On the other hand, the metadata is saved to Dynamodb, and when a new save entry triggers an event to create an ECS task to perform other operations (such as generating a GIF graph)

"Summarizing" the MicroServices (microservices) architecture in an AWS cloud computing environment

Contact Us

The content source of this page is from Internet, which doesn't represent Alibaba Cloud's opinion; products and services mentioned on that page don't have any relationship with Alibaba Cloud. If the content of the page makes you feel confusing, please write us an email, we will handle the problem within 5 days after receiving your email.

If you find any instances of plagiarism from the community, please send an email to: info-contact@alibabacloud.com and provide relevant evidence. A staff member will contact you within 5 working days.

A Free Trial That Lets You Build Big!

Start building with 50+ products and up to 12 months usage for Elastic Compute Service

  • Sales Support

    1 on 1 presale consultation

  • After-Sales Support

    24/7 Technical Support 6 Free Tickets per Quarter Faster Response

  • Alibaba Cloud offers highly flexible support services tailored to meet your exact needs.