By Jianxin.
In the Xianyu app ecosystem-which is Alibaba's major second-hand buy-sell platform in China-you can find all sorts of relationships. You could say that the relationship that is most apparent in the ecosystem, of course, is the one between buyers and sellers. This sort of relationship is triggered by the buyer showing interest in the item the seller has posted through his or her interaction with the item and buyer, specifically through actions such as searching for the item, favoriting it, or chatting with the seller. Another major type of interaction in the Xianyu app ecosystem is the relationships that exist between users and the platform itself. With these, however, there are some technical difficulties to overcome:
For the current system working behind the scenes on Xianyu, you can think of it all as a matter of conditions that trigger corresponding actions. You can confront the issues discussed above when this paradigm is enriched with the concept and service of IFTTT.
IFTTT is a free web-based service that uses a type of concept called "Network Automation Artifact". Generally speaking, it's a relationally practical and simple concept. "IFTTT" is a crafty little abbreviation of the phrase "If This Then That", which just means that if a "this" condition is met, a "that" action is triggered. Conceptually, then, "IFTTT" consists of three parts: a trigger (being "this"), an action (being "that") and a recipe (being the entire condition-result clause set).
The concept behind IFTTT itself is not complex. Rather, the real magic of IFTTT lies in the complexity resulting from the combination of these simple components. That is, of course, to say that, when many simple IFTTT processes are connected with each other, a state machine spanning the entire Internet can be formed, with multiple platforms and multiple devices involved and impacted.
IFTTT in the Xianyu app ecosystem can be generated based on the combination of several service scenarios and the IFTTT concept. In the Xianyu ecosystem, the IFTTT standard protocol can be encapsulated, which can make for a non-invasive and scalable service orchestration system.
The two main features of the IFTTT system implemented in Xianyu correspond to the above two problems:
By "Multidimensional", what is meant is coverage of several different kinds of user interactions. That is, the system of IFTTT used at Xianyu is one that both abstracts and also enriches user relationships through the collecting information about a larger range of dimensions. Then, based on richer user relationship data, the team at Xianyu can generate better user profiles and also reach users on the platform in a more effective manner.
The IFTTT system on Xianyu also provides efficient storage and processing capabilities for data collected on user relationships at the underlying layer, which in turn also supports real-time processing of user relationships in upper-layer services. Next, this system also supports bidirectional relationships between the seller and buyer.
The IFTTT system on Xianyu can switch previous interactions between the platform and users and connections between buyers and sellers into natural interactions between various Xianyu users. All of this, in practical terms, makes for a better overall experience in the app ecosystem for everyone. All of this was designed based on the technical scenario that will be discussed in the following section:
Now let's consider the technical scenario and solution that is involved at Xianyu. For this solution, the service is modeled according to the IFTTT specification, which is further divided into the Channel (think "relationships", "directions", and "dimensions", so on), Trigger, and Action layers. Generally speaking, as you can see from the graphic above, the Channel layer is the underlying data layer. It associates the Trigger and Action layers to form the resulting Recipe. Below is a more detailed explanation of each of these layers:
Consider the detailed diagram below, which outlines the technical solution of the IFTTT system used for Xianyu:
The overall technical solution, shown above, has been refined based on the structure diagram of service modeling, to supplement the dependent technical components. Although the overall process is not described in detail here, detailed descriptions about the key modules in the process are given below:
The quick scenario access module is one of the most important modules of the system. The purpose of designing such a module is make services on Xianyu work seamlessly so everything appears to work in relative real-time for app users. Because in the initial design, the scenario access is used to report the service data and scenarios by adding Aspect-Oriented Programming (AOP) in the service logic. However, this method doesn't provide the best overall experience as it increases the response times of service operations and it work well for all scenarios.
The quick scenario access module solves these problems. First, for this module, Log Service is used to access the massive network request logs of all applications to record the request addresses, parameters, and responses. Next, Log Service is used as the data source for Blink StreamCompute tasks. Network request addresses and parameters are filtered in real time according to the rules dynamically distributed by Diamond, and the data is assembled according to the specified format and reported to the Channel layer.
The quick scenario access solution decouples service logic from scenario access. It supports quick access, flexible changes, and low latency, and is a high-performance solution for big data scenario access.
Next, there is the module for computing lists of users, which adopts the responsibility chain model, because in different Trigger scenarios, the computing and filtering logic of the service to the user list are different. With the responsibility chain model, then, the main process is decoupled from the service filtering logic, and various services are supported to flexibly customize the filtering logic without interfering with each other.
Next, following this, the Action layer is the most important part of the IFTTT system implemented at Xianyu. It can reach the users directly. The Action logic can directly affect user activity and their overall feelings and experience about the app and ecosystem in general. The Push message is the most common logic in the Action layer, and it is necessary to prevent users from being harassed. The PushAction logic is as follows:
"Fatigue" for the IFTTT system at Xianyu is the key concept in preventing users from feeling they are being harassed by the system-or, to put it more bluntly, receiving too many message notifications from the app. At the Xianyu team, they designed fatigue into the three layers discussed above. The first layer is user-level fatigue, which controls the number of messages a user receives in a cycle. The second layer is the service dimension fatigue, which controls the number of messages that a user receives for a service in a cycle. The third layer is the target-level fatigue, which controls the number of messages that a user receives from the same sender in a cycle.
At the service dimension layer, flexible control of joint fatigue of multiple services is supported to ensure that users will not be unduly harassed by messages.
User relationship data is one of the most important aspect of the IFTTT system implemented on Xianyu. It features a large storage capacity, being several terabytes in size. Next, it requires high performance for both storage and query operations, with transaction and queries per second values being well above 10,000 during peak hours for the app. After much research, the Xianyu team found that the Lindorm database developed within Alibaba Group could meet all of these requirements.
Lindorm is a high-performance KV storage database independently developed by Alibaba based on Hbase. It optimizes both the performance and stability of Hbase to some extent. The IFTTT system of Xianyu uses Lindorm as the storage of user relationship data. Performance tests show that the queries per second recording for data reading can get up to 70,000, and the transactions per second recording for data storage can be over 100,000. Lindorm has excellent performance and has lain the foundation for the high performance of IFTTT.
Since its launch, the IFTTT system for Xianyu has helped by providing additional support for multiple service scenarios. Moreover, it can help to provide near real- or real-time and bidirectional interactions and connections between buyers and sellers in the Xianyu platform. On average, it can process hundreds of millions pieces of relational data every day. The amount of processed Triggers can get up in the tens of millions, and the amount of processed Actions can get into the hundreds of millions. The Message CTR is more than doubled compared to that of offline Push.
The IFTTT system at Xianyu currently supports user interaction scenarios. In the future, the team at Xianyu plan to combine the service features of IdleFish itself to abstract IFTTT in a higher dimension and encapsulate the standard Recipe interface, turning the IdleFish IFTTT into a service platform that provides process orchestration and management capabilities.
IFTTT systems have already enjoyed much popularity outside of China-being implemented in the backbones of many systems used by major tech giants. So by no means Alibaba is not alone in this regard. In fact, since its launch in 2010, IFTTT has been used extensively. Several tech companies and teams alike have been using in both Internet and IoT fields. Although the concept of IFTTT is simple, it can help meet the high demands of users through standardized protocols, enabling various Internet products to serve users. This also gives the Internet practitioners at Xianyu and Alibaba in general some ideas ideas: In the face of new opportunities, is it more important to invest quickly? Or is it more effective to solve a type of problem by abstracting standard protocols?
How Can Tens of Millions of Data Records Be Processed Every Second?
How Hundreds of Millions of Items are Filtered and Organized on Xianyu
56 posts | 4 followers
FollowXianYu Tech - June 22, 2020
XianYu Tech - November 10, 2020
XianYu Tech - June 22, 2020
XianYu Tech - March 11, 2020
XianYu Tech - September 3, 2020
Alibaba Tech - June 4, 2019
56 posts | 4 followers
Follow
Simple Log Service
An all-in-one service for log-type data
Learn More
Retail Solution
Alibaba Cloud enables digital retail transformation to fuel growth and realize an omnichannel customer experience throughout the consumer journey.
Learn More
Big Data Consulting Services for Retail Solution
Alibaba Cloud experts provide retailers with a lightweight and customized big data consulting service to help you assess your big data maturity and plan your big data journey.
Learn More
Log Management for AIOps Solution
Log into an artificial intelligence for IT operations (AIOps) environment with an intelligent, all-in-one, and out-of-the-box log management solution
Learn MoreMore Posts by XianYu Tech
