This article explains how Alibaba Cloud's Message Service can help you build a more reliable application by addressing potential issues on a microservices architecture.
Some time back, deploying a monolithic application was so simple. You'd take out a bare metal server, install all the necessary software and heap all your application code, data and assets onto it. This kind of application would handle massive traffic and was very easy to administer and deploy, since everything was on one machine. However, it did have many inefficiencies that were eventually exposed. For example, you'd have to estimate your peak load and take out a server big enough to handle it, but a majority of these resources lay idle at normal load and were a real waste at minimal load. Furthermore, scaling this machine up remains a painful manual task, if one component needed more resources than the machine had, the whole machine had to be brought down affecting all other components! The bare metal, admittedly, is still the best fit for certain use cases but their inefficiencies have been rightfully taken over by the microservices architecture.
The microservices architecture is a software development technique that structures an application as a collection of loosely coupled services. The services are fine-grained and the protocols lightweight thus improving application modularity making it easier to understand, develop, and test. It parallelizes development by enabling small autonomous teams to develop, deploy and scale their respective services independently. Microservices-based architectures enable continuous delivery and deployment.
So, instead of deploying all your code, databases, and assets on one server. You divided each into separate groups which can all be executed independent of the other. So you have code that is responsible for uploading, manipulating and saving an image, and a specific storage meant just for it. You have code that is responsible for checking and creating sessions and a specific database just for it. You have a specific block of code to handle new user posts, another block (or service) to check it for profanity, a database to store the comment, another one to search it by keywords, and so on.
The major benefit is that now, each microservice can be scaled, up or down, according to usage, thus saving precious resources. Another benefit is that you can now have a much better separation of concerns for developers and engineers, those responsible for databases, those who write backend code, the UI/UX people and so on. Another major benefit is that, since each service is working independent of the other, individual components can now achieve a higher uptime guarantee. This is because, one stressed out component cannot affect another and also because upgrading one component does not mean taking down the other.
But they say everything has its advantages and disadvantages. One of the main disadvantages of the microservices architecture is application uptime guarantee. Huh? Yes, this can be a bit confusing, see by decoupling the entire application into microservices, you improve each individual component's reliability but at the cost of your application's overall reliability. Let's dive a bit deeper into this.
In the monolithic bare-metal application, if the server has an issue, be it network, hard drive, memory or otherwise, the whole application goes down. So, if your provider gave you a 99.5% uptime guarantee, then you are confident of being up 99.5% of the time, however, with the microservice architecture, each component has its own uptime guarantee. So, if your application uses 10 services, each with 99.5% guarantee, then you now have 99.5% to the power of 10 = 95.0%. This number is now not so pretty, to put this in a better context, you now expect to be down for 5 whole seconds, in every 100. The situation is much worse if your provider gave you a 99% guarantee which translates to a 90% uptime guarantee for the entire application, or that you now expect to be down for 10 whole seconds, in every 100.
Does this mean that the microservices architecture is bad? Not at all, it just means that over and above using microservices, developers need to take measures to guard their application from potential downtime. One way to do this is, rather ironically, by introducing another microservice! And one such service is Alibaba Cloud's Message Service.
Alibaba Cloud Message Service is a distributed message queuing and notification service that supports concurrent operations to facilitate message transfer between applications and decoupled systems. Alibaba Cloud Message Service enables users to move data between distributed applications to achieve complex tasks, and build decoupled fault tolerant applications.
If you haven't already, sign up on Alibaba Cloud. You can use this link to get $300 in free credit to test out the Message Service.
In this article, we will use a queue based model of Alibaba Cloud's Message Service to receive message and automatically submit jobs in Batch Compute.
Batch Compute is a distributed cloud service suitable for processing massive volumes of data concurrently. The system automates resource management, job scheduling, and data loading and supports billing on a Pay-As-You-Go basis. This tutorial demonstrates how you can submit or schedule jobs automatically simply by sending message from Alibaba Cloud Message Service.
Alibaba Cloud Message Service is a high performance, reliable, safe, extensible distributed message and notification service that supports massive messages, concurrent operations. It help facilitate message transfer between applications and system decoupling.
We will use Queue based model of messaging service to receive message and automatically submit job in batch compute.
There are various real world applications of this idea. For example,
In this tutorial, we will simulate the message alert using send message function in Message Service web console. From the console, job names will be passed as message text or body to consumer script. Consumer is a custom python script, which will monitor messages from Message Queue in certain frequencies and depending on the message text received, consumer will submit the job corresponds to the job name mentioned in each message.
This tutorial can easily be understood and followed if you are familiar with the below technologies and conceipts,
https://www.alibabacloud.com/referral?referralCode=kwfk44
In this tutorial, we will investigate how you can achieve more resilience by decoupling using the queues and topics of Alibaba Cloud's Message Notification Service.
When you have an application with lots of moving parts, ensuring the availability of your services can be a real challenge. If one of the components goes down, a tightly coupled architecture might cause the error to snowball. This can quickly take down your full application and sometimes requires several hours to fix. Decoupling the components in your application can help prevent the snowball effect and increase availability. In this post, we will investigate how you can achieve more resilience by using the queues and topics of the Alibaba Cloud Message Notification Service.
Let us say you run a webshop that sells shoes. Logically, you have an order processing component that receives incoming orders and checks the stock levels. If the shoes are in stock, a payment is triggered. Finally, a delivery is scheduled with a third party logistic service provider. As the project had a tight schedule, the team decided to put the workflow in a single component that handles these tasks from top to bottom. The application went live and people started ordering. On Friday afternoon that week, you get a phone call: the servers of the logistic service provider are down. People have ordered shoes and paid for them, but the application was unable to schedule any deliveries. This means the customers will never get their new shoes. There are two ways to recover from this. You can either undo the payment and fail the order, or wait until the logistic service provider resolves the issues and try to manually fabricate the needed messages. All in all, you are in a pickle.
How could these issues have been prevented? By decoupling the coupled architecture! In a more decoupled approach, the workflow will be processed by multiple individual components. Every component receives a message, does its work and triggers the next step in the workflow. If a step fails, that component can retry the processing for as long as it sees fit. The failure will not influence any other steps in the process, although it might take a little bit longer before orders can be finalized. But a customer would probably be happy to wait for a few minutes, rather than not being able to order at all.
Decoupling an application using messages like this is usually done using queues and topics, that we will look at next.
When you know that only a single logical component should receive a message, you can use a queue. A queue is a stack of messages that a component can receive one by one. The receiving component is sometimes called a consumer. If a message was processed successfully, it is removed from the queue. If something unexpected happens during the processing of a message, it is put back on the queue. The message will then be received again at a later point in time. Normally, consumers can decide for themselves how many messages they will process concurrently, so the throughput is at an acceptable rate. It is also very common to see multiple consumers for any given queue.
Queues are ideal for batch calculations, generating invoices or images, sending emails or doing any kind of work that takes a fair amount of time. The beauty of it is that the component that sends the message, the producer, can keep on sending messages even if the consumer is down. The queue will fill up with messages that will be processed when the consumer comes up again. In this way, not a single message gets lost if an outage occurs. That makes an application more resilient and ensures a good user experience.
Topics can be used if multiple components should receive a message. These consumers are called subscribers in the context of a topic. The messages on a topic are often events triggered by the application. An example might be that an order was processed. Multiple subscribers might be interested in that event, like the shipment service and the payment service. Theoretically, a topic differs from a queue because the publishing side does not know anything about the consumers. It has no idea how many components will pick up the message, nor does it know what subscribers might want to do with it. This is a very powerful concept and sometimes referred to as a Publish-Subscribe pattern.
The best thing about queues and topics is that you can combine them to create an extremely flexible setup. When adding subscribers to a topic, you can specify the transport protocol of the message. An HTTP call can be made whenever a message is published on the topic, but you could also have the message delivered into a queue. That way, the fault tolerance of queues is combined with the fan-out kind of architecture topics provide.
Enough with all the theory. To get a feel for how queues and topics can help decouple application components, let us create a simple demo application that uses both queues and topics. To get started, log in to the Alibaba Cloud console and find the Message Notification Service (MNS).
This article describes the architecture of an IM system and introduces a Table Store-based message synchronization and storage system architecture.
IM is the abbreviation of instant messaging. In the highly information-based mobile Internet era, IM products have become a must-have item in our life. The most well-known IM products in China are DingTalk, WeChat, and QQ. Among them, WeChat has already developed into an ecosystem, but its core function is still an IM. IM is an inseparable module of some applications that do not take IM as the core business. The most typical ones are online games and social networking applications. The IM feature is essential to applications with social attributes.
The IM system came into being in the early days of the Internet. Its basic technology architecture has been updated many times during the last dozen of years—from the early CS and P2P architectures to the current distributed systems in the backend. It involves all aspects of technologies, such as mobile clients, network, security, and storage. The daily active users that an IM product serves have increased from a small number in the early days to up to 900 million as announced by WeChat recently.
The core of an IM system is the messaging system, and the core function of the messaging system is the synchronization and storage of messages:
The article mainly describes the messaging system architecture in the IM system. We will introduce the implementation of a Table Store-based message synchronization and storage system architecture. It supports advanced features of the messaging system, such as "multi-end synchronization" and "message roaming". In terms of performance and scale, it supports full message storage on the cloud, and message synchronization with millions of TPS and millisecond delays.
This section mainly describes the architecture design of Table Store-based modern IM systems. Before describing the architecture design in detail, we will introduce the timeline logic model to abstract and simplify the understanding of the IM synchronization and storage models. After understanding the timeline model, we will talk about the modeling methods for the synchronization and storage of messages based on the timeline model. We also have to make technical trade-offs in various aspects when implementing message synchronization and storage. For example, we have to compare and choose common pull and push modes for message synchronization, and choose the underlying database based on the characteristics of the timeline model.
Comparison between Conventional and Modern Architectures
The above diagram is a simple comparison between the conventional and modern architectures of a messaging system.
Under a conventional architecture, messages are synchronized first before they are stored. For online users, messages are directly synchronized to online recipients in real time. After a message is successfully synchronized, it will not be persisted. For offline users or messages that cannot be synchronized in real time, the messages will be persisted to an offline database. The recipient may pull all unread messages from the offline database after reconnecting to the Internet. A message will be deleted from the offline database after it is successfully synchronized to the recipient. Main tasks of the conventional messaging system server is to maintain the connection between the sender and the recipient, and to provide online message synchronization and offline message caching. This design ensures messages can be transmitted from the sender to the recipient under all circumstances. The server does not persist the message, so it does not support message roaming.
Under the modern architecture, messages are stored first and then synchronized. The advantage of storing messages before synchronization is that when a recipient receives a message, the message must have already been saved on the cloud. In addition, the messages are saved in two databases—the message storage database and the message synchronization database. The message storage database stores messages of all sessions to support message roaming. The message synchronization database is mainly used for multiple-terminal synchronization of the recipient. After a message is sent by the sender, it is forwarded by the server. The server subsequently saves the message to the message storage database and the message synchronization database. After a message is persisted, if the recipient is online, the message is pushed to recipient directly. However, online push is not the only option. It's just the preferred one. For messages that failed to be pushed online, or when the recipient is offline, there is another unified message synchronization method. The recipient will actively pull all unsynchronized messages from the server. However, the time of synchronization, and from which terminals the recipient may send the message synchronization requests are unknown to the server. So, the server must save all messages that need to be synchronized to the recipient. This is what the message synchronization database is designed for. Users of an IM product may have message roaming needs when they use new devices. The message storage database is designed to meet such needs. From the message storage database, you can pull all historical messages for any session.
The above is a simple comparison between the conventional and modern IM system architectures. The modern architecture supports multi-terminal synchronization and message roaming without making the entire message synchronization and storage process much more complicated. The core of the modern architecture is the two message database—the "message synchronization database" and "message storage database". They are the foundation of message synchronization and storage. The next section of this article will mainly describe the design and implementation of these two databases.
In this short video, we introduced what is Alibaba Cloud Message Service and how to send/receive message through the console.
To find out more detail about Message Service, please access:
https://www.alibabacloud.com/product/message-service
Alibaba Cloud's Short Message Service provides the APIs and SDK to developers to send messages all around the world. The system supports OTP (One-Time-Password), transaction notifications, push notifications and promotional campaigns as well as supports both domestic and international messaging. It covers the globe, Alibaba SMS provides convenient, efficient, and intelligent communication capabilities that help businesses quickly contact their customers.
This course is designed to help businesses that want to use Message Queue services, as well as cloud computing engineers and enthusiasts who want to understand and learn Message Queue technology. By learning this course, you can fully understand what is Message Queue and how to use Alibaba Cloud MQ, which can provide reference for practical application
Through this course, you can understand the advantages and concepts of Alibaba Cloud MQ, and be able to start using Alibaba Cloud MQ.
This course is designed to help developers and engineers who want to open APIs or call APIs, as well as cloud computing technology enthusiasts who are interested in API Gateway. Through this course, learners can fully understand what API gateway is, how to call APIs, how to open APIs, and the scenarios of using API Gateway on Alibaba Cloud, so as to provide a reference of using APIs and API gateway.
This interface is used to send a message to the specified message queue. A common message can be consumed by the consumer immediately after being sent to a message queue. The producer can set the DelaySeconds parameter when sending the message to consume later (the typical scenario is a scheduled task). The initial status of a message with the DelaySeconds value(>0) is Delayed. The message can not be consumed till its status turns to Active after its DelaySeconds time expires.
The priority of the DelaySeconds parameter specified upon message sending is higher than the DelaySeconds attribute of the delayed message queue. That means, when the values of the two DelaySeconds attributes are different, the value of the DelaySeconds parameter specified upon message sending takes precedence.
Message Queue for Apache RocketMQ provides asynchronous decoupling and load shifting for distributed application systems, and supports features for Internet applications, including massive message accumulation, high throughput, and reliable retry.
In addition to internet access, Message Queue for Apache RocketMQ supports private networks for application infrastructure, namely Virtual Private Cloud (VPC) access. You have full control over your VPC, which you can define and customize by specifying the IP address range and configuring route tables and network gateways. You can also launch Alibaba Cloud resources such as Elastic Compute Service (ECS), Relational Database Service (RDS), and Server Load Balancer (SLB) in your own VPC.
A message queuing and notification service that facilitates smooth transfer of messages between applications
AlibabaMQ for Apache RocketMQ is a distributed message queue service that supports reliable message-based asynchronous communication among microservices, distributed systems, and serverless applications.
2,599 posts | 764 followers
FollowAlibaba Clouder - June 16, 2020
Alibaba Cloud Native Community - July 20, 2023
Alibaba Container Service - December 4, 2024
Anna Chat APP - July 18, 2024
Alibaba Cloud Native - March 12, 2024
Hologres - May 31, 2022
2,599 posts | 764 followers
Follow
Message Queue for Apache Kafka
A fully-managed Apache Kafka service to help you quickly build data pipelines for your big data analytics.
Learn More
AliwareMQ for IoT
A message service designed for IoT and mobile Internet (MI).
Learn MoreMore Posts by Alibaba Clouder
