Preface

Last year, I needed to write a text message platform. After the development was completed, I have not organized and shared it. Taking advantage of the remaining temperature, I will share the general ideas and processes (not specific code, only design patterns, development ideas, flow charts) Information), some design patterns and some knowledge of fusing will be used in the middle. I hope I can provide you with some ideas or gains.
Let me talk about the situation before and after the development of the SMS platform

Status before development:

Multiple places in the project need to send SMS messages and develop them separately, resulting in N multiple identical SDKs and redundant codes in one project;

Maintenance costs are too high. If there is a change of SMS service provider, it will take a lot of time to adjust

SMS copywriting is not standardized and cannot be effectively controlled. Alibaba’s SMS requires the creation of templates and signatures first, but some SMS service providers do not need them (not for example). You can control the text of the SMS yourself and send it directly through the interface. There is no way to control it well.

Easy to be swiped, security cannot be guaranteed, and it is impossible to make a set of anti-sweeping solutions wherever you develop your own SMS

The SMS log is too messy, and there is no guarantee that each log is recorded and recorded in a certain format

Status after development:

The most intuitive, convenient for every programmer who needs SMS service to develop, originally needed a lot of code, now only needs, a registration step + combination of sending parameters + one line of initiation request

Unified log, each log can be accurately recorded, SMS initiator, sending time, sending template, sending content, SMS platform callback result, etc., can be seen

More convenient maintenance, from the original multi-point maintenance to the current one, as long as the SMS platform maintains a single maintenance, and can be insensitive to the caller

The back-end interface of SMS settings management can be used for SMS service provider management, signature management, theme (simple can be understood as a collection of SMS template and SMS provider) management, circuit breaker configuration, and traffic control;

Different themes for different SMS service providers (many-to-many), flexible configuration

Security center, unified entrance, more convenient security measures (not necessary, this part can be achieved through the gateway)

The multi-service provider mode cooperates with the fuse setting. When a short message service provider hangs up, the service provider will switch to continue sending without any impact on the user.

Unified request format and return format

design phase

core concept

theme

In the current project, the concept of a theme is a collection that contains all the information of a short message template:

The identification of the SMS (the unique identification that the demander must fill in when registering the SMS, and it will be sent through the identification when sending the SMS)

Subject name (easy to view)

Subject type (convenient to filter, such as verification code, marketing SMS, notification SMS, etc.)

Text message content (for example, [your verification code is {code} and your mobile phone number is {phone}]. If there are variables, use a fixed format to wrap them)

Substitution variable (for the text message content has a variable, you need to fill in this item [code|phone])

SMS service provider (There can be multiple SMS service providers under one theme, and the weight can be set to match the ratio on demand. Or when one service provider hangs up, you can change to another service provider to send SMS in time)

Template name (the name of the SMS template under the service provider for easy viewing)

Service provider mark (need to be managed by a separate service provider, here just need to associate service provider information)

Weight (the weight of the service provider to send SMS, the higher the weight, the higher the probability of priority sending)

Platform extension information (here is more important, you need to set up special parts of the platform, such as Ali’s internal SMS template information, if you need to send SMS through Ali, you need to configure Ali’s template id here, for example { "TemplateCode": "SMS_123456"}, will associate the template, find Ali's method of sending SMS through the strategy mode, pass the SMS template information and the variable value sent to send the SMS. If there are other places that need to be set, you can Configure here and implement it in the interface for each service provider to send text messages)

The above is the general content and meaning of the theme, which contains a lot of content, including SMS service provider management , SMS service provider signature management , theme type management, etc., which will be introduced below.

Other management centers

Here is just a brief introduction, not a detailed interface introduction, everyone’s design is different, and unreasonable places are lightly sprayed. Different suggestions are welcome.

SMS service provider management

Multi-service provider management, manage the information of each SMS service provider, including

Service provider identifier (the theme will associate the service provider through this identifier) Service provider name (easy to view)
extended parameters (need to configure the unique information of each service provider, such as account, password, apiurl, etc., the information required by the service provider platform)
Weight (literally, set a value within 1-100 to indicate weight. When sending text messages, priority will be dispatched to the higher weight, and the dispatch center will specifically introduce a simple method to calculate the weight)
fuse setting

Cumulative failure times (if the cumulative number of request failures exceeds the current setting times, a circuit breaker will be added)

Number of consecutive successes (after adding fuse, if the number of consecutive requests succeeded in an indirect request exceeds the current set number of times, contact fuse)

Each time the fuse fails, the increase time (just enter the fuse and continue to request failure after the fuse, the increased request time interval, will be introduced later)

The maximum fusing time of fusing failure (continuous failure after fusing, continuously increase the maximum value of the request time interval)

Theme type management

Mainly for the screening of topics, such as verification codes, notifications, marketing SMS, etc. Will be associated with the subject.

SMS service provider signature management

The main consideration is the possibility of multiple signatures under one service provider. In the case of many-to-many, signature management is required.
The signature of the service provider under the subject of the main association. You can use your own unique service provider and signature under each theme.

Four centers

Security center

In order to avoid being swiped, you can design the part of the security center. Every request needs to be verified. There are many verification methods, such as IP whitelisting, encryption verification, etc.
Of course, IP can also be realized through the gateway. In fact, I recommend security measures in the gateway part. This is more in line with the concept of microservices. All request entry processing is done through the gateway.

Traffic center

When the volume is large, it can be used as a flow center to control the maximum and minimum limits of the flow. For example, to accurately control the number of SMS sent or received by each mobile phone number or each SMS subject (for example: the number of login verification codes received by each mobile phone number in one day, the general service provider will do a control, if we need it , You can do it on your own platform for more precise control).
This part can also play some functions to prevent being swiped, for example, limit the number of mobile phone numbers that can be received for some promotional text messages and so on. Of course, this can only be auxiliary safety.

Dispatch center

The core part of the SMS platform is the dispatch center , which is a fusing and dispatching platform.
Here I only introduce the concepts in my project. If you understand it differently, don't worry, you are right.

Fuse

The following is an explanation from Baidu

Fuse mechanism
fusing mechanism (Circuit Breaker), also known as automatic stop plate mechanism refers to measures to suspend trading when the stock reaches a predetermined amplitude point fuse, exchange control risks taken. [1] Specifically, it is a mechanism for setting a fuse price for a certain contract before reaching the price limit, so that the contract buying and selling price can only be traded within this price range for a period of time.

In the stock market, it is a suspension of trading measures to control risks.
This is almost the same meaning in technology. When a platform fails to reach our preset number of failures in a period of time, it will enter a circuit breaker. In the next period of time, it will try to send a request occasionally to test it. If this This kind of trial how many times all succeeds in succession then resumes fusing, if it fails, increases the fusing time.
Corresponding to the SMS platform, we have a multi-service provider model. Under each theme, multiple SMS service providers will be set up. When a service provider hangs up and several consecutive requests fail, we will think that the service provider is unavailable in the short term. Will fuse. In the case of fusing, there will be regular requests to the fusing server to send short messages. If the sending fails, increase the fusing time of the periodic request and increase the request interval. In the case of fusing, if the request is successful for several consecutive times, we will consider the service provider to recover Normal, release the fuse.

Scheduling

The following is an explanation from Baidu

Dispatching center (dispatching center): Refers to a center for comprehensive scheduling of multiple resources. Dispatched resources include natural resources and social resources. Natural resources include electricity, water power, natural gas, etc. Social resources include personnel, vehicles, materials, etc.

It can be understood literally, that is, rationally schedule resources to ensure the normal operation of the system.
In the system, we mainly do two kinds of scheduling, fuse and weight.
Priority: Fuse> Weight
We will first consider the fuse, get all platforms that are not in the fuse period + platforms that can be interrupted by the fuse, and then calculate these platform data based on the weight. The fuse will not be repeated, the most In the configuration part mentioned at the beginning and the fuse logic part mentioned above, it should be possible to know how to do the fuse.
For the calculation method of weight, I made a demo of PHP and tried to add all the comments. It is relatively simple. If you have a better method, please leave a message.
I have done several tests in private and output the results. It is obvious that the current three platforms, a and b have more priority.

// 模拟平台数据
$platform = [
    [
        'name' => 'a',	// 平台名称
        'weight' => 30,	// 权重
    ],
    [
        'name' => 'b',
        'weight' => 70,
    ],
    [
        'name' => 'c',
        'weight' => 50,
    ]
];

// 测试排序后的数组的值
print_r(getWeight($platform));

// 递归获取根据权重排序后的平台顺序
function getWeight($platform)
{
    
    
    $resultData = [];   // 保存最终排序的数组
    $min = 1; // 初始化权重范围最小值
    $sum = 0;  // 初始化权重范围最大值
    $weightList = [];  // 初始化存放权重数据的数组

    // 如果只剩下一个平台，就不需要在判断，直接获取就可以
    if (count($platform) == 1) {
    
    
        $weightList[] = $platform;
        return $platform;
    }

    foreach($platform as $key => $platformOne) {
    
    
        $sum += $platformOne['weight']; // 获取当前权重范围最大值
        // 把当前平台权重换算成范围写入到权重数组中，
        $weightList[$key] = [
            'name' => $platformOne['name'],
            'min' => $min,  // 该范围的最小值
            'max' => $sum   // 该范围的最大值
        ];

        $min = $sum + 1; // 获得下一个平台的最小值
    }

    // 得到具体的随机数,1到权重总值之间的一个随机数
    $randNum = mt_rand(1, $sum);

    // 循环每一个权重范围的数组
    foreach($weightList as $k => $weightOne) {
    
    
        // 根据随机数及每个平台的权重范围得到当前最优先的，并把该平台从数组中刨除掉
        if (($weightOne['min'] <= $randNum)  && ($weightOne['max'] >= $randNum)) {
    
    
            $weightOne['randNum'] = $randNum;
            $resultData[] = $platform[$k];
            unset($platform[$k]);
            break;
        }
    }

    // 递归调用，把其他的平台重新按权重排序
    $resultData = array_merge($resultData, getWeight($platform));

    // 返回最终排好序的平台数组
    return $resultData;
}

Of course, scheduling is not only like this. If we only need to get the platform with the highest priority, we will not get a priority ranking of all platforms. We also need to consider that if the platform with the highest priority fails to send SMS this time What should I do? Is it just to return a sending failure to the user? This is impossible. Then our multi-platform advantages will be lost. We still need to do one step. When the highest priority sending fails, we will judge the current SMS platform for fuse ( fuse will only be triggered here. It can be triggered asynchronously here ), and the next platform will send it in sequence until the sending is successful ( judge the current platform fuse status, if it is fuse, the number of successes + 1; if the current number of successes exceeds the set number of fuse successes, the fuse is released .This can be processed asynchronously ), or all fail.

Log center

The log center is relatively simple. It records all successful and failed SMS sending records, and records related platform information, template information, signature information, etc.
Use the observer mode or strategy mode to do the callback part.
In addition to the log, an alarm system is also needed. For example, when the platform fails to send SMS, fails to call back, triggers a fuse, and other exceptions, we need to monitor, the simplest is: Too much file log + Dingding alarm, you can make detailed information into a file log, and then use Dingding alarm to notify us of any errors that have occurred, and you can coordinate and repair as soon as possible.

flow chart

What is inevitable in development is the flow chart. A good flow chart can intuitively see whether the logic is reasonable, whether the business or code flow is smooth, whether there are obvious bugs, etc.

The following is the basic flow chart.
Click here to jump to the original address of the flow chart List item
to initiate a request to an interface or microservice -> Security Center Detection -> Obtain SMS Subject Information -> Flow Control -> Dispatch Center (Including Fuse) -> Send SMS -> End
Mind Map I won’t write any more, because too many business parts are involved and it’s not convenient to extract them. However, the introduction above can basically reflect the various components.

SMS platform technology sharing (to be continued)

SMS platform