Given n asynchronous tasks, these n asynchronous tasks must be executed sequentially, and each subsequent asynchronous task depends on the result of the previous one as its parameter. How do we implement this?

Solution 1: for loop + await

A simple for loop iterates sequentially, unlike Array.forEach and Array.map, which execute concurrently. Leveraging this characteristic along with async / await, it is easy to write code like the following:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

(async () => {
  const sleep = delay => {
    return new Promise((resolve, reject) => {
      setTimeout(_ => resolve(), delay)
    })
  }
  
  const task = (i) => {
    return new Promise(async (resolve, reject) => {
      await sleep(500)
      console.log(`now is ${i}`)
      ++i
      resolve(i)
    })
  }
  
  let param = 0
  for (let i = 0; i < 4; i++) {
    param = await task(param)
  }  
})()

Output:

1
2
3
4

now is 0
now is 1
now is 2
now is 3

Although this achieves the desired effect, the param local variable is rather unpleasant to look at. See Solution 2.

Solution 2: Array.prototype.reduce

When most people first encounter the Array.prototype.reduce method, they use it to sum an array. If you are not familiar with it, you can click the link to learn about reduce.

reduce has the concepts of an initial value, an accumulator, and a current value. The accumulator can be thought of as the previous value, and by returning the accumulator it can also be thought of as the next value (this may sound convoluted; you can refer to the source code of Redux’s middleware execution order, which also uses reduce). The code that uses reduce to solve the problem is:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

const sleep = delay => {
  return new Promise((resolve, reject) => {
    setTimeout(_ => resolve(), delay)
  })
}

const task = (i) => {
  return new Promise(async (resolve, reject) => {
    await sleep(500)
    console.log(`now is ${i}`)
    ++i
    resolve(i)
  })
}

[task, task, task, task].reduce(async (prev, task) => {
  const res = await prev
  return task(res)
}, 0)

Output:

1
2
3
4

now is 0
now is 1
now is 2
now is 3

You can understand prev and task as follows:

• prev: the previous asynchronous task (promise)
• task: the current asynchronous task

The current asynchronous task needs the result of the previous asynchronous task as its parameter, so it obviously needs to await prev.

1
2
3
4

function simpleURL(protocol, domain, path) {
    return protocol + "://" + domain + "/" + path;
}
simpleURL('http','www.jackzxl.net', 'index.html');     //http://www.jackzxl.net/index.html

This is a perfectly ordinary function with nothing remarkable about it. But for your own site, the first argument is fixed to http, and the second is fixed to www.jackzxl.net; only the third argument ever changes. In other words, for any page or resource on your site, the first two arguments are always the same, and you only need to vary the third.

Obviously you don’t want to manually type those first two arguments every time you call the function — it’s tedious and error-prone. So what can you do? You might think about simply rewriting the library function to take a single argument:

1
2
3

function simpleURL(path) {
    return "http://www.jackzxl.net/" + path;
}

This change has two problems. First, if the library function is also used by other people or in other places, modifying it directly is out of the question. Second, even if you have full control over the function, this approach is inflexible — what if one day you want to enable SSL on your site? You’d have to put the first argument back. The correct choice, therefore, is currying. Currying means: binding a function to a subset of its arguments and returning a new function. If that feels abstract, you can draw an analogy to partial specialization in C++ templates, which makes it easier to grasp. Let’s curry the example above:

1
2
3
4
5
6

var myURL = simpleURL.bind(null, 'http', 'www.jackzxl.net');
myURL('myfile.js');     //http://www.jackzxl.net/myfile.js

// The site adds SSL
var mySslURL = simpleURL.bind(null, 'https', 'www.jackzxl.net');
mySslURL('myfile.js');  //https://www.jackzxl.net/myfile.js

The code above uses bind to implement currying. Now revisit the definition of currying: binding a function to a subset of its arguments and returning a new function. After currying, the function becomes more flexible and more fluent — it’s a concise way to delegate behavior. Why use bind to implement currying? Because it’s simple — there’s no need to reinvent the wheel when a built-in is already available. But since this post is about currying, let’s implement it ourselves to deepen our understanding. It needs to satisfy two requirements: accept a subset of arguments, and return a new function:

1
2
3
4
5
6
7
8
9
10

var currying = function(fn) {
    var args = [].slice.call(arguments, 1);
    return function() {
        var newArgs = args.concat([].slice.call(arguments));
        return fn.apply(null, newArgs);
    };
};

var myURL2 = currying(simpleURL, 'https', 'www.jackzxl.net');
myURL2('myfile.js');    //http://www.jackzxl.net/myfile.js

The effect is the same as using bind. Let’s examine the custom currying function more closely: the first argument, fn, is the function to be curried (simpleURL), and the rest are variadic arguments (for more on a function’s arguments, see here). The result of each line in currying is as follows:

1
2
3
4
5
6
7
8
9
10
11
12

var currying = function(fn) {
    var args = [].slice.call(arguments, 1);
    // args is ["https", "www.jackzxl.net"]

    return function() {
        var newArgs = args.concat([].slice.call(arguments));
        // newArgs is ["https", "www.jackzxl.net", "myFile.js"]

        return fn.apply(null, newArgs);
        // equivalent to return simpleURL("https", "www.jackzxl.net", "myFile.js");
    };
};

We’ve now covered the principle and the implementation of currying. So what is currying actually good for? The common benefits are:

• Parameter reuse
• Deferred execution
• Flattening

Parameter reuse was already demonstrated in the example above, so I won’t belabor it.

Deferred execution is actually very intuitive: because the function returns a new function instead of a computed result, execution is naturally deferred. For example, bind is a representative case of deferred execution, so again I won’t dwell on it.

Flattening makes functions more readable. For instance, suppose you want to extract the titles of all posts from your site’s JSON data:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

// JSON data
{
    "user": "Jack",
    "posts": [
        { "title": "JavaScript Curry", "contents": "..." },
        { "title": " JavaScript Function", "contents": "..." }
    ]
}

// Get the titles of all posts from the JSON data
fetchFromServer()
    .then(JSON.parse)
    .then(function(data){ return data.posts })
    .then(function(posts){
        return posts.map(function(post){ return post.title })
    })

Of course you could write more elegant code than this… but that’s beside the point. The point is to use currying to make the code more readable and maintainable:

1
2
3
4
5
6
7

var curry = require('curry');
var get = curry(function(property, object){ return object[property] });

fetchFromServer()
    .then(JSON.parse)
    .then(get('posts'))
    .then(map(get('title')))

Early return?

Finally, another use case you’ll find online is early return. For example, IE handles events differently from other browsers; to achieve compatibility you could write:

1
2
3
4
5
6
7
8
9
10
11

var addEvent = (function(){
    if (target.addEventListener) {
        return function(target, eventType, handler) {
            target.addEventListener(eventType, handler, false);
        };
    } else {        // IE
        return function(target, eventType, handler) {
            target.attachEvent("on" + eventType, handler);
        };
    }
})();  

In my view, however, currying doesn’t add much value here. Currying certainly has many advantages, but it has equally obvious drawbacks — notably a non-trivial learning curve. Using currying to implement “early return” costs more in maintenance than it gains.

How can you achieve the same thing without currying? A single ternary operator does the trick:

1
2
3
4
5
6
7

var addHandler = document.body.addEventListener ?
    function(target, eventType, handler){
        target.addEventListener(eventType, handler, false);
    } :
    function(target, eventType, handler){
        target.attachEvent("on" + eventType, handler);
    };

Or you can rewrite the function from within itself:

1
2
3
4
5
6
7
8
9
10
11
12

function addHandler(target, eventType, handler){
    if (target.addEventListener){
        addHandler = function(target, eventType, handler){  // rewrite this function
            target.addEventListener(eventType, handler, false);
        };
    } else {        // IE
        addHandler = function(target, eventType, handler){  // rewrite this function
            target.attachEvent("on" + eventType, handler);
        };
    }
    addHandler(target, eventType, handler); // call the new function
}

Both approaches are straightforward and crystal clear. Don’t reach for currying just for the sake of using currying.

Summary

Although currying has a somewhat mysterious name, it isn’t really mysterious once you see through it. On the frontend its use cases are limited (though that may just reflect my own limited experience); it’s more often applied to asynchronous functions on the backend, such as in Node.js, where currying async APIs can reduce callback nesting.

Source: https://www.jianshu.com/p/9b6b5c7527fc

Problems We Once Faced

Vipshop is a mid-sized internet company in terms of scale, and we hope our practices can serve as a reference for peers of a similar size.

Vipshop’s business logic is quite extensive. Beyond e-commerce, it also covers logistics and finance. During the early phase of rapid growth, the priority was to ship features quickly, which resulted in a wide variety of technology architectures. Later on, the introduction of third-party software for the finance business also brought some less-than-standard practices.

Different teams handled different business lines. Because the business lines were not unified, operations had many blind spots, making it hard to share headcount.

We built a large number of platforms for release, change management, and so on, yet it always felt like something was missing. We could not form a strong enough force to support the business teams, and we were operating in a fragmented way. Because the technology stacks were inconsistent, building platforms meant accounting for all kinds of special cases and even making compromises.

So we began to reflect:

• First, how can engineers strike a balance among quality, cost, and efficiency? The diagram below highlights the key questions. No one can claim to have perfected all three; the goal is to find the best balance point among them.
• Second, after building so many tooling platforms, why are operations staff still exhausted?
• Third, while racing headlong forward on operations platform construction, how do we stay true to our original intent?

From this we summarized four lessons:

• First, platform builders must deeply understand the pain points of operations.
• Second, technology selection for platform construction is not the most important factor; truly understanding operations is what matters most. That is not to say technology selection is unimportant — it just is not the most important.
• Third, the degree of standardization sets the ceiling for operations automation.
• Fourth, the level of automation determines new growth points for operations. In a word: standardization is urgent.

The Road of Standardization Construction

The Component Concept

The component mindset laid the foundation for standardization:

• On the technical growth side, our approach is to have component expert teams take charge. The expert team defines the direction of the component and explores best practices, which supports technical accumulation and the skill development of the team members.
• Component-based service-ification: operations staff transform outward into technology output, providing service-based products. Developers only need to consume standard APIs without worrying about underlying details.
• Eliminate business silos and give business teams new goals to pursue.

Standardization Construction Blueprint

This is the big picture of standardization construction. Operations standardization is a very large program, so we split it into more than a dozen smaller projects.

Combined with Vipshop’s business characteristics, we broke it down based on the company’s specific business situation. On the left is the technology process stack, and on the right are the deliverables. The items in red relate to business characteristics, while those below red relate to operations.

Configuration Repository Management

When a developer submits a request for operations to change a configuration in production, it is very painful. Does the developer have permission to do it themselves? Or does operations handle it — but operations doesn’t understand it, while the developer thinks operations is clueless and can’t be bothered to explain. Operations has no time to study hundreds of business systems.

The solution is layered governance: let the specialists do what they specialize in.

For example, when a shopping-cart parameter change affects business logic, that kind of task is handed to the developers. Tasks related to components are handled by the expert team.

Of course, developers cannot directly modify files in some path on production. So we built the Janitors platform, which organizes all kinds of configuration files in a standardized way and grants developers permission to manage the parameters of their own business systems, allowing them to make changes that take effect immediately.

Operations focuses on the layer below, performing operations management based on Puppet.

Monitoring Standardization

When the number of machines exceeds 10,000, Zabbix becomes overwhelmed. Vipshop initially ran multiple sets of Zabbix for monitoring.

Ideal monitoring:

• Unified, fast, and precise
• A single entry point
• Automated, with standardized monitoring plugins
• No manual intervention required for deploying or adding monitoring
• Standardized monitoring plugins. Everyone has their own idea of what monitoring standards should be, and the result is multiple monitoring metrics — which can be fatal.
• Customizable monitoring views that fully unlock the value of the data. This is operations-leaning. We want to maximize the value of the runtime metrics from production — to see which systems make money while using the fewest resources, and which systems burn money while consuming the most.
• Empower developers and keep the system scalable.

None of the above is satisfied by Zabbix.

Breakdown of monitoring standardization goals:

• The first layer is the event source, i.e., CMDB application information standardization.
• The second layer is monitoring module standardization. The expert team is responsible for designing monitoring and setting thresholds for technical components, with monitoring templates placed under unified version control.
• The third layer is alerting rule standardization. The monitoring system and the alerting system are decoupled, each with its own responsibility. Alerts are differentiated by device tier, application tier, and severity.

The unified source for alert recipients is the CMDB.

We built our own product, VIPFalcon, based on secondary development of open-falcon. It currently monitors around 25,000 nodes with more than 5 million metrics, and uses data stream computing to re-aggregate the collected data. This data lands in Hive for data analysis, fully unlocking the value of the data.

After monitoring standardization, comparing VIPFalcon with Zabbix: from a single place you can see all the infrastructure monitoring information of the entire company, without needing multiple entry points. In terms of collection extensibility, VIPFalcon is plugin-based, oriented around the HostGroup dimension, and maintained via Git. In terms of management, integration with the operations ecosystem, and programming language support, VIPFalcon is well ahead of Zabbix.

As a result of this work, internally we achieved quality improvements, higher work efficiency, lower maintenance costs, better user experience, and better risk control.

Outwardly, we exported value by opening up the operations ecosystem, empowering developers, and helping them think about resource usage from their perspective.

Fine-grained operations and business cost accounting are an output of the value of the data.

Change Standardization

Changes are tightly coupled with everyone in operations — every “blame” that operations takes is related to this area. The key is two ideas:

• First, we proposed a risk matrix. We built an SDK. To describe the matrix in one sentence: it splits the original change risk into two dimensions — the object and the technical risk. Briefly, the object refers to a business system: it may be a core system, an important system, or an unimportant one. We can profile it and assign a score. Combined together, these give each change a precise score.
• A standard change template library means that changes go through expert-designed templates for every change to each component. Changes must be based on the experts’ templates; you cannot improvise a change plan however you like.

After this work was solidified, we turned all kinds of changes into individual APPs, so that on the change platform you can supply parameters and execute a change with one click.

Connecting the Ecosystem and Empowering Everyone

What do we mean by ecosystem? We have built many automation systems. If each one still requires a person to perform a task — for example, making a change still requires someone to click buttons — we are still in the early stage of automation. The ecosystem we want to build is one where systems drive systems; all systems interact through API calls, and humans are involved as little as possible.

CMDB Replaces Process

To connect the operations ecosystem, the original approach was process-centric. Most people dislike processes; no one really loves them. Later, we shifted to an approach centered on operations processes + the CMDB. A process is a rather dogmatic thing. For example, a process might tell me that I can do change A at 3 PM this afternoon — but can I really? It does not weigh the context, the object, or the timing. If the object has a problem at 3 PM, the process should not proceed, but the process naively tells you to go ahead.

This is Vipshop’s specific business. In the middle are process control and a CMDB-centric approach, and from top to bottom are the operations-related deliverables — from components, to deployment standards, to all kinds of self-service platforms. Once the processes are connected, monitoring can fire alerts, and we want monitoring to drive self-healing. For example, when a disk alert reaches 90%, an alert is generated, which invokes a disk-cleanup APP on the automation platform, and that APP executes the cleanup. After cleanup, it tells the monitoring system to send a text message: a 90% alert was detected and the cleanup has been executed. This is a fairly ideal working state, and it has already been realized.

Approach to Connecting Changes

When it comes to ecosystem connectivity, our initial thinking was rather grand. We originally wanted to design a perfect process that would completely connect everything. We later realized that was naive; it is very hard to have a perfect plan that connects all the operations-related tooling. So our approach shifted to connecting them one by one. For example, to connect systems A, B, C, and D: first connect A-B, then connect C-D. A few issues with changes are ones that everyone encounters (see the slides). We built a very good and very flexible automated change system, but this is a double-edged sword: DevOps changes can go out of control and change processes may not be followed.

Design principles for connecting changes:

• First, the process system provides an SDK to all automation tools, offering change control, change collection, and SDK self-governance capabilities.
• Second, the automation capability platform sorts out the change risk matrix, integrates the SDK, and reports the change risk matrix.
• Third, the process system provides an SDK to all automation tools, offering change control, change collection, and SDK self-governance capabilities.

This is one of our systems (see diagram below). In the middle is a standard template library where the technical expert team designed a set of standard changes. The SDK is linked on the left side to the load balancing management platform, the scheduled-task management platform, the cloud platform, the operations platform, and others — connecting these platforms to empower developers.

When a developer wants to make a simple configuration change on a business line, the old way was for the developer to find operations and ask for the change. Operations would say “wait,” submit a change process, and once the process was rolling, find that the boss wasn’t around and the boss’s approval was needed. If everything went smoothly, this took the better part of a day.

Now the developer submits a request on the tools platform, and if central control considers the risk very low, it goes through directly — the developer’s task is done.

The benefit is that standard changes are solidified, processes are simplified, change risk is effectively controlled, and developers are empowered.

Monitoring Connectivity Enables Automation

Our idea is that across the entire server lifecycle — initialization, deployment, running, pausing, and service decommissioning — none of the monitoring setup requires manual intervention. All entry points are connected between the monitoring system and the CMDB. There is only one source of information: the CMDB. When the CMDB detects a change in some piece of information, it writes to a message queue; the monitoring system then consumes that queue and executes the corresponding monitoring mount or unmount flow.

This is the concrete implementation (see diagram below). In the middle is still the monitoring system, and on the left are alerting and data aggregation.

After the previous standardization and ecosystem connectivity, the gains are twofold:

• First, operations finally has comprehensive, centralized data. Monitoring data is captured, all production change data is in hand, and runtime data all settles into a unified pool. Why is this important? If you want to do AIOps, everything is empty talk without data. By connecting the ecosystem this way, data is deposited in one place, laying the groundwork for future intelligent operations.
• Second, through these efforts, we struck a balance between efficiency and process — ensuring efficiency while keeping risk under control.

Looking Back

Returning to the three questions posed at the beginning, there are clear gains across quality, efficiency, and cost.

• On quality, we transformed from manual labor into platform builders, taking the first step from automation toward intelligence.
• On efficiency, we lowered the barrier to entry, improved efficiency, and enforced process control.
• On cost, after aggregating the data, we profiled each application and gained data-backed insight into resource utilization.

A Few Reflections

• Only on the soil of standardization can automation and intelligence take root and grow.
• Standardization requires strong leadership and a clear methodology.
• DevOps construction needs a business perspective. We don’t do technology for technology’s sake; we build around cost, quality, and efficiency, and the vision for platform building should aim higher.
• A single branch of service must be consolidated into a combined-arms force to deliver real combat power. Climbing one more rung up the food chain depends on the ability to integrate.

This article gives a concise and approachable explanation of the design rationale and operating flow of OAuth 2.0. The primary reference is RFC 6749.

1. Application Scenario

To understand where OAuth applies, let me use a hypothetical example.

Imagine a website called “Cloud Photo Print” that can print photos a user has stored on Google. To use this service, the user must allow “Cloud Photo Print” to read the photos they have stored on Google.

The problem is that Google will only let “Cloud Photo Print” read those photos if the user authorizes it. So how does “Cloud Photo Print” obtain the user’s authorization?

The traditional approach is for the user to give their Google username and password to “Cloud Photo Print”, which then reads the user’s photos. This approach has several serious drawbacks:

1. “Cloud Photo Print” would store the user’s password for subsequent services, which is highly insecure.
2. Google would have to deploy password-based login, and as we know, plain password login is not secure.
3. “Cloud Photo Print” would gain the power to access everything the user has stored on Google, and the user would have no way to limit the scope or validity period of the authorization granted to “Cloud Photo Print”.
4. The only way for the user to revoke the power granted to “Cloud Photo Print” is to change their password. But doing so would also invalidate every other third-party application the user has authorized.
5. If any single third-party application is compromised, the user’s password would be leaked, along with all data protected by that password.

OAuth was created to solve exactly these problems.

2. Terminology

Before diving into OAuth 2.0, we need to understand a few specialized terms. They are essential for following the rest of the explanation, especially the diagrams.

1. Third-party application: the third-party application, also referred to as the “client” in this article – i.e., “Cloud Photo Print” in the example above.
2. HTTP service: the HTTP service provider, also referred to as the “service provider” in this article – i.e., Google in the example above.
3. Resource Owner: the resource owner, also referred to as the “user” in this article.
4. User Agent: the user agent, which in this article means the browser.
5. Authorization server: the authorization server, the server the service provider uses specifically to handle authentication.
6. Resource server: the resource server, the server where the service provider stores user-generated resources. It may be the same server as the authorization server, or a different one.

With these terms in mind, it is not hard to see that the purpose of OAuth is to let the “client” securely and controllably obtain the “user’s” authorization and interact with the “service provider”.

3. The Idea Behind OAuth

OAuth introduces an authorization layer between the “client” and the “service provider”. The “client” cannot log in directly to the “service provider”; it can only log in to the authorization layer, which keeps the user and the client separate. The token used by the “client” to log in to the authorization layer is different from the user’s password. At login time, the user can specify the scope and validity period of the authorization-layer token.

Once the “client” has logged in to the authorization layer, the “service provider” opens up the user’s stored data to the “client” based on the token’s scope and validity period.

4. Operating Flow

The operating flow of OAuth 2.0 is shown in the diagram below, taken from RFC 6749.

A. After the user opens the client, the client requests authorization from the user.
B. The user agrees to grant the client authorization.
C. The client uses the authorization obtained in the previous step to request a token from the authorization server.
D. The authorization server authenticates the client and, once everything checks out, agrees to issue a token.
E. The client uses the token to request resources from the resource server.
F. The resource server verifies the token and agrees to expose resources to the client.

It is easy to see that among these six steps, B is the key – i.e., how the user grants authorization to the client. With this authorization, the client can obtain a token, and then use that token to obtain resources.

The following sections explain the four authorization modes one by one.

5. Client Authorization Modes

The client must obtain the user’s authorization grant before it can receive an access token. OAuth 2.0 defines four authorization modes.

• Authorization Code
• Implicit
• Resource Owner Password Credentials
• Client Credentials

5.1. Authorization Code Mode

Authorization Code mode is the most feature-complete and rigorous of the authorization flows. Its defining characteristic is that the client’s back-end server interacts directly with the “service provider’s” authorization server.

A. The user accesses the client, which then redirects the user to the authorization server.
B. The user chooses whether to grant the client authorization.
C. Assuming the user grants authorization, the authorization server redirects the user to a “redirection URI” previously registered by the client, and includes an authorization code.
D. The client receives the authorization code and, together with the earlier “redirection URI”, requests a token from the authorization server. This step happens on the client’s back-end server and is invisible to the user.
E. The authorization server verifies the authorization code and the redirection URI, and once everything checks out, sends an access token and a refresh token to the client.

Below are the parameters required for each of these steps.

In step A, the URI the client uses to request authorization contains the following parameters:

• response_type: indicates the authorization type, required; the value here is fixed as “code”.

• client_id: the client ID, required.

• redirect_uri: the redirection URI, optional.

• scope: the scope of access being requested, optional.

• state: the client’s current state; any value may be used, and the authorization server will return it verbatim.

1
2

GET /authorize?response_type=code&client_id=s6BhdRkqt3&state=xyz&redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb HTTP/1.1
Host: server.example.com

In step C, the URI the server uses to respond to the client contains the following parameters:

• code: the authorization code, required. The code should have a very short validity period, typically set to 10 minutes, and the client may use it only once; otherwise the authorization server will reject it. The code is bound one-to-one to the client ID and the redirection URI.

• state: if the client’s request contained this parameter, the authorization server’s response must include it with exactly the same value.

1
2

HTTP/1.1 302 Found
Location: https://client.example.com/cb?code=SplxlOBeZQQYbYS6WxSbIA&state=xyz

In step D, the HTTP request the client sends to the authorization server to request a token contains the following parameters:

• grant_type: indicates the authorization mode being used, required; the value here is fixed as “authorization_code”.

• code: the authorization code obtained in the previous step, required.

• redirect_uri: the redirection URI, required; it must match the value used in step A.

• client_id: the client ID, required.

1
2
3
4
5
6

POST /token HTTP/1.1
Host: server.example.com
Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW
Content-Type: application/x-www-form-urlencoded

grant_type=authorization_code&code=SplxlOBeZQQYbYS6WxSbIA&redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb

In step E, the HTTP response from the authorization server contains the following parameters:

• access_token: the access token, required.

• token_type: the token type, required; the value is case-insensitive and can be of type “bearer” or “mac”.

• expires_in: the expiration time, in seconds. If omitted, the expiration time must be set through some other means.

• refresh_token: the refresh token, used to obtain the next access token; optional.

• scope: the scope of access; if it matches the scope requested by the client, this field may be omitted.

1
2
3
4
5
6
7
8
9
10
11
12

HTTP/1.1 200 OK
Content-Type: application/json;charset=UTF-8
Cache-Control: no-store
Pragma: no-cache

{    
   "access_token":"2YotnFZFEjr1zCsicMWpAA",
   "token_type":"example",
   "expires_in":3600,
   "refresh_token":"tGzv3JOkF0XG5Qx2TlKWIA",
   "example_parameter":"example_value"
}

As you can see from the code above, the relevant parameters are sent in JSON format (Content-Type: application/json). In addition, the HTTP headers explicitly specify that the response must not be cached.

5.2 Implicit Mode

The Implicit grant type does not go through the third-party application’s server; instead, it requests a token directly from the authorization server in the browser, skipping the “authorization code” step – hence the name. All steps take place in the browser, the token is visible to the visitor, and the client does not need to be authenticated.

A. The client redirects the user to the authorization server.
B. The user decides whether to grant the client authorization.
C. Assuming the user grants authorization, the authorization server redirects the user to the “redirection URI” specified by the client and includes the access token in the fragment portion of the URI.
D. The browser sends a request to the resource server, without the fragment value received in the previous step.
E. The resource server returns a web page containing code that can extract the token from the fragment.
F. The browser executes the script obtained in the previous step and extracts the token.
G. The browser sends the token to the client.

Below are the parameters required for these steps.
In step A, the HTTP request sent by the client contains the following parameters:

• response_type: indicates the authorization type; the value here is fixed as “token”, required.

• client_id: the client ID, required.

• redirect_uri: the redirection URI, optional.

• scope: the scope of access, optional.

• state: the client’s current state; any value may be used, and the authorization server will return it verbatim.

1
2

GET /authorize?response_type=token&client_id=s6BhdRkqt3&state=xyz&redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb HTTP/1.1
Host: server.example.com

In step C, the URI the authorization server returns to the client contains the following parameters:

• access_token: the access token, required.

• token_type: the token type, required; the value is case-insensitive.

• expires_in: the expiration time, in seconds. If omitted, the expiration time must be set through some other means.

• scope: the scope of access; if it matches the scope requested by the client, this field may be omitted.

• state: if the client’s request contained this parameter, the authorization server’s response must include it with exactly the same value.

1
2

HTTP/1.1 302 Found
Location: http://example.com/cb#access_token=2YotnFZFEjr1zCsicMWpAA&state=xyz&token_type=example&expires_in=3600

In the example above, the authorization server uses the Location field of the HTTP headers to specify the URL the browser should be redirected to. Note that the token is contained in the fragment portion of this URL.

Following step D, the browser next visits the URL specified by Location, but the fragment portion is not sent. In step E, the code served by the service provider’s resource server extracts the token from the fragment.

5.3 Password Mode

In Password mode (Resource Owner Password Credentials Grant), the user provides their username and password directly to the client. The client uses this information to request authorization from the “service provider”.

In this mode, the user must hand their password to the client, but the client must not store the password. This is typically used in situations where the user has a high degree of trust in the client – for example, when the client is part of the operating system or is produced by a well-known company. The authorization server should only consider this mode when the other authorization modes cannot be used.

A. The user provides their username and password to the client.
B. The client sends the username and password to the authorization server, requesting a token from it.
C. The authorization server verifies everything and, once it checks out, provides the client with an access token.

In step B, the HTTP request sent by the client contains the following parameters:

• grant_type: indicates the authorization type; the value here is fixed as “password”, required.

• username: the username, required.

• password: the user’s password, required.

• scope: the scope of access, optional.

1
2
3
4
5
6

POST /token HTTP/1.1
Host: server.example.com
Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW
Content-Type: application/x-www-form-urlencoded

grant_type=password&username=johndoe&password=A3ddj3w

In step C, the authorization server sends the access token to the client. Here is an example.

1
2
3
4
5
6
7
8
9
10
11
12

HTTP/1.1 200 OK
Content-Type: application/json;charset=UTF-8
Cache-Control: no-store
Pragma: no-cache

{
  "access_token":"2YotnFZFEjr1zCsicMWpAA",
  "token_type":"example",
  "expires_in":3600,
  "refresh_token":"tGzv3JOkF0XG5Qx2TlKWIA",
  "example_parameter":"example_value"
}

For the meaning of each parameter in the code above, see the “Authorization Code Mode” section.

Throughout the entire process, the client must not save the user’s password.

5.4 Client Credentials Mode

In Client Credentials mode, the client authenticates with the “service provider” on its own behalf, rather than on behalf of the user. Strictly speaking, Client Credentials mode does not fall under the problem the OAuth framework is designed to solve. In this mode, the user registers directly with the client, and the client requests services from the “service provider” in its own name – there is really no authorization problem to speak of.

A. The client authenticates itself with the authorization server and requests an access token.
B. The authorization server verifies everything and, once it checks out, provides the client with an access token.

In step A, the HTTP request sent by the client contains the following parameters:

• granttype: indicates the authorization type; the value here is fixed as “clientcredentials”, required.

• scope: the scope of access, optional.

1
2
3
4
5
6

POST /token HTTP/1.1
Host: server.example.com
Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW
Content-Type: application/x-www-form-urlencoded

grant_type=client_credentials

The authorization server must verify the client’s identity in some way.

In step B, the authorization server sends the access token to the client. Here is an example.

1
2
3
4
5
6
7
8
9
10
11

HTTP/1.1 200 OK
Content-Type: application/json;charset=UTF-8
Cache-Control: no-store
Pragma: no-cache

{
  "access_token":"2YotnFZFEjr1zCsicMWpAA",
  "token_type":"example",
  "expires_in":3600,
  "example_parameter":"example_value"
}

For the meaning of each parameter in the code above, see the “Authorization Code Mode” section.

5.5 Refreshing the Token

If, when the user tries to access the service, the client’s “access token” has already expired, the client must use a “refresh token” to request a new access token.

The HTTP request the client sends to refresh the token contains the following parameters:

• granttype: indicates the authorization mode being used; the value here is fixed as “refreshtoken”, required.

• refresh_token: the refresh token received earlier, required.

• scope: the scope of access being requested; it must not exceed the scope of the previous request. If this parameter is omitted, the scope is treated as identical to the previous one.

1
2
3
4
5
6

POST /token HTTP/1.1
Host: server.example.com
Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW
Content-Type: application/x-www-form-urlencoded

grant_type=refresh_token&refresh_token=tGzv3JOkF0XG5Qx2TlKWIA

Source: http://www.ruanyifeng.com/blog/2014/05/oauth_2_0.html

What Is Architecture

• Personnel allocation and project planning within a department
• Floor planning and functional facility planning in building design
• Road layout, functional building design, and entertainment facility design in a city
• Urban planning, expressway planning, and high-speed rail route planning for a country

  All is architecture!!!

The Essence of Architecture

• Core lifecycle: Sub-lifecycles whose subject remains unchanged after splitting.
• Non-core lifecycle: Sub-lifecycles whose subject changes after splitting.
  

  The essence of architecture lies in continuously splitting lifecycles (in a tree structure) so that business can run in parallel spatially. Each lifecycle that is split off has its own boundary and does not affect other lifecycles; all changes are settled within its own lifecycle. This is what high cohesion means.

Software Architecture

Software lifecycle: software development lifecycle + software runtime lifecycle (software access, software features, software monitoring)

Three Elements of Good Software Architecture

• Firmness: Achieve a satisfactory level of freedom from damaging failure.
• Commodity: Utility to accomplish the tasks it is purported to be for.
• Delight: Pleasure in use.

  Buildings (Solid, Useful, Beautiful) -> Software (Firmness, Commodity, Delight)

Overview of the Architecture Process

1. Business architecture: A top-down view of the architecture, including business rules, business modules, and business processes. It mainly decomposes the business of the whole system, designs the domain models, and transforms real-world business into abstract objects.
2. Technical architecture: A cross-sectional view of the architecture, an abstraction from hardware to application, including abstraction layers and programming interfaces. Technical architecture and business architecture are complementary; every part of the business architecture has its own technical architecture. These two parts must be done well first.
3. Data architecture: The storage architecture, mainly referring to the design of data structures. It determines the characteristics of the application’s data sources and is the foundation of both business architecture and technical architecture.
4. Deployment architecture: The topology architecture, including how many nodes the system is deployed on, the relationships between nodes, high availability of servers, fault tolerance, network interfaces and protocols, etc. It determines how the application runs, its runtime performance, maintainability, and scalability, and is the foundation of all architectures.
5. Organizational architecture: The team architecture, including the organizational form of the project, personnel composition, and responsibilities. It is the supporting facility for all the architectures above. A good organizational architecture ensures the effective implementation and advancement of the other architectures.

   As business and load change, the architecture needs to be continuously reviewed and refactored to drive its evolution.

Business Architecture

• Business execution is the core module of the application and its primary function.
• Data analysis is an auxiliary module of the application, helping with data-driven R&D, business intelligence research, and improving user experience.
• System management is the foundational part of the application. Doing a good job of deployment, monitoring of various metrics, and backup of critical data helps the application iterate and deploy quickly and run stably.

Technical Architecture - Overview

• Business data sources, data rule engines, and analysis rules support the presentation of the interactive UI.
• Infrastructure and common services build up the underlying business logic.

Technical Architecture - Specifics

• Both UI and applications belong to the application layer, which provides the concrete business implementation. Among them, UI is the primary form of expression for the view layer.
• Applications and services belong to the control logic and access channels, where services hold the main business logic. Services can expose service interfaces for applications to call.
• Core, drivers, and data make up the data layer. This is the operation logic for all data related to the business and corresponds to the model layer. Among them, the core can expose interfaces outward for services to call.

Evolution of Architecture

• In a monolithic application architecture, all logic resides within the application and core modules, including business logic, data operations, and so on.
• Through a data-driven approach, data operation interfaces are unified to shield the differences between data sources, allowing vertical partitioning based on resources.
• Modules are decoupled and expose APIs outward as services, forming a distributed service architecture.

Deployment Architecture

• The interactive UI is deployed independently, including forms such as web and app.
• The application is deployed independently as a single node or a cluster.
• Services, the core, and drivers are deployed as a whole.
• Data sources are deployed independently.
• A simple application/service cluster: LVS (using keepalived for active/standby) + Nginx (reverse proxy) + Tomcat (business container).

Data Architecture

• The data interaction logic and data flow presented by the interactive UI determine the main data design of the business.
• The original business data, logs, and the data needed for statistics support the report output required by data analysis.
• Real-time information, under certain rules and state machine engines, can power dashboard features such as real-time status monitoring.

Five Attributes of Data

• Access frequency: Read/write frequency. Read-only and frequently accessed data can be redundantly stored in multiple copies.
• Consistency requirement: Data with high consistency requirements must be strictly guaranteed to be accurate.
• Access permission: In API design, data of different granularities is exposed according to different permissions. PO -> VO is a description of the same entity under different permissions.
• Data importance: Cannot be lost / partial loss allowed / only a cache / no need to persist.
• Data confidentiality: Plaintext internally allowed / plaintext internally not allowed / can be made public.

Data Design

• Fully understand the interactive UI so you know which data the UI is associated with and which data can be cached.
• Fully understand the business so you know clearly which data needs to be recorded and the relationships between data.
• Database design should pay attention to storage efficiency:
  • Reduce transactions
  • Reduce JOIN queries
  • Use indexes appropriately
  • Consider using caching
  • …
• In data statistics scenarios, data statistics with high real-time requirements can use Redis; non-real-time data can use separate tables, with data updated through asynchronous queue computation or scheduled calculations. In addition, for statistical data with high consistency requirements, transactions or scheduled reconciliation mechanisms are needed to ensure accuracy.

What Is an Architect

• Lifecycle identification: rationally split lifecycles.
• Identify problems and the subject of the problem. Never mistake a solution for a problem. Discovering a problem is always more important than solving it!!!
• Focus on business and technology, and ensure business growth.
• OKR architecture: be responsible for breakthroughs in key technologies, resolve technical feasibility issues, and deliver the key results that take things from 0 to 1.
• Authority must match responsibility, to ensure the architecture is executed!!!

Essential Qualities of an Architect

• Stand high, see far, dig deep.
• Master a certain technology so you can draw analogies at a fundamental level and quickly grasp other technologies.
• Treat all technologies equally: there is only suitable or unsuitable, never liked or disliked.
• Have a broad vision, understand the pros and cons of different technologies, know which open-source project can directly satisfy this or that requirement, and be able to judge whether you need to reinvent the wheel.
• Master design patterns, but do not overuse them.
• Split the system into multiple subsystems or modules, keeping modules as loosely coupled as possible, so that development tasks that previously could only run serially can proceed in parallel, and the timeline can be shortened by investing more people.
• Clearly know where the system’s bottlenecks are, continuously locate bottlenecks in technical difficulty, R&D progress, performance, memory, and other aspects, constantly assign key personnel to resolve bottlenecks, and eliminate hidden risks before they explode.
• Be able to anticipate how requirements may change and make forward-looking designs accordingly.

Six-Step Architecture Thinking Method

Architecture Principles - Overview

Architecture Principles

• Avoid over-engineering: The simplest solution is the easiest to implement and maintain and also avoids wasting resources. But the solution should include provisions for extension.
• Redundancy design: Provide node redundancy for services and databases to ensure high availability. This is achieved through database master-slave replication and application clusters.
• Active-active data centers: For disaster recovery and to fundamentally guarantee high availability of the application. Multiple active data centers must be built so that a failure of one data center due to uncontrollable factors does not render the entire system unavailable.
• Stateless design: APIs, interfaces, and so on must not have front-back dependencies; one resource is not affected by changes to another. A stateless system can scale better. If state is unavoidable, either the client manages it or the server manages it with a distributed cache.
• Rollback capability: Any business, especially critical business, must have a recovery mechanism. This can be implemented with log-based WAL or event-based Event Sourcing, etc.
• Disabling / self-protection: Provide rate-limiting mechanisms so that when upstream traffic exceeds the system’s load capacity, overflowing requests can be rejected. This can be done via manual switches or automatic switches (monitoring abnormal traffic behavior) to block traffic at the front of the application.
• Traceability: When a problem occurs in the system, you can locate the trajectory of the request and the request information at each step. Distributed tracing systems solve this kind of problem.
• Monitorability: Being monitorable is key to keeping the system running stably. This includes monitoring of business logic, application processes, and system resources the application depends on (CPU, disk, etc.). Every system needs to monitor well at these levels.
• Fault isolation: Isolating the resources (threads, CPU) and services that a system depends on ensures that a failure of one service does not affect calls to other services. Fault isolation can be achieved through thread pools or by deploying nodes separately.
• Mature and controllable technology selection: Use mainstream, mature technologies with good documentation and ample support resources. Choose the appropriate technology rather than the hottest one to implement the system.
• Tiered storage: Memory -> SSD disk -> traditional hard disk -> magnetic tape. Data can be stored in tiers according to its importance and lifecycle.
• Caching design: Isolating requests from backend logic and storage is a mechanism based on the locality principle. This includes client-side caching (pre-distributing resources), Nginx caching, local caching, and distributed caching.
• Asynchronous design: For interfaces where the caller does not care about the result or allows a delayed result, responding asynchronously via a queue can significantly improve system performance; when calling other services, not waiting for the service to return before returning directly also improves response performance. Asynchronous queues are also a common means of solving distributed transactions.
• Forward-looking design: Based on industry experience and judgment, design extensibility and backward compatibility in advance.
• Horizontal scaling: Compared to vertical scaling, being able to solve problems by adding more machines is the top priority, and the system’s load capacity can scale close to infinitely. In addition, automatically adjusting capacity based on system load via cloud computing technology can save costs while ensuring service availability.
• Build and release in small steps: Iterate the project quickly, and fail fast. Avoid project plans with overly long spans of time.
• Automation: Automating packaging and testing is called continuous integration; automating deployment is called continuous deployment. Automation is the fundamental guarantee for rapid iteration and trial-and-error.

Architecture Principle - Scalability

• X-axis: horizontal duplication or cloning, goal-oriented. Examples include database read-write separation, table replication, replication, etc. Monolithic applications or dependent services are made redundant, and load balancing improves the system’s load capacity.
• Y-axis: function/service-oriented, such as vertical applications and distributed services. This splits a monolithic application into smaller applications or services based on function.
• Z-axis: resource-oriented, such as horizontal database sharding. Resources are partitioned to spread the load across different nodes.

  • Avoid relying on the database’s computational features (functions, stored procedures, triggers, etc.). Put the load on the business application side, which is easier to scale.
  • Scalability plan principle: Design for 20x, implement for 3x, deploy for 1.5x (DID).

Five Techniques for Improving System Response Performance

• Asynchrony: Queue buffering, asynchronous requests.
• Concurrency: Use multiple CPUs and threads to execute business logic.
• Locality principle: Caching, tiered storage.
• Reduce IO: Merge fine-grained interfaces into coarse-grained ones; for frequent overwrite operations, only perform the last one. One thing to pay special attention to here: avoid calling external services inside loops in your code. A better practice is to use a coarse-grained batch interface outside the loop and make a single request.
• Partitioning: Keep the size of frequently accessed data sets within a reasonable range.

References

• “Scalability Rules” by Martin L. Abbott / Michael T. Fisher (Chinese edition edited by Chen Bin)
• “Liao Liao Jia Gou (On Architecture)” by Wang Gaikai
• “An Architect’s First Lesson” by Cai Xueyong
• Six-Step Architecture Thinking Method by Xia Huaxia @ Meituan

Source: http://www.rowkey.me/arch-ppt/index.html

In the object-oriented era, there were many well-known design principles, patterns, and anti-patterns, for example:

• [SOLID][SOLID] (Single Responsibility, Open-Closed, Liskov Substitution, Interface Segregation, and Dependency Inversion)

• Design Patterns: Elements of Reusable Object-Oriented Software

• Anti-Pattern

In the new container context, the corresponding principles and patterns help us build better “cloud-native” applications. As we will see, these principles and patterns are not a wholesale rejection of previous patterns; rather, they are evolutionary versions adapted to the new environment.

Principles

Single Concern Principle (SCP)

Corresponding to the single responsibility of OO, each container should provide a single concern and focus on doing one thing well. A single concern makes a container easier to reuse. Typically a container corresponds to one process, and that process focuses on doing one thing well.

High Observability Principle (HOP)

Containers, like objects, should be well-encapsulated black boxes. However, in a cloud environment, this black box should expose good observability interfaces so that it can be monitored and managed appropriately in the cloud. In this way, the entire application can provide consistent lifecycle management.

Observability includes:

• Providing health checks, or heartbeats
• Providing status
• Outputting logs to standard output (STDOUT) and standard error (STDERR)
• etc.

Life-Cycle Conformance Principle (LCP)

The life-cycle conformance principle means that containers should interact with the platform to handle the corresponding lifecycle changes.

• Capture and respond to the Terminate (SIGTERM) signal to gracefully terminate the service process as quickly as possible, in order to avoid being forcibly killed by the kill (SIGKILL) signal. For example, the following NodeJS code.

1
2
3
4
5
6

process.on('SIGTERM', function () {
  console.log("Received SIGTERM. Exiting.")
  server.close(function () {
    process.exit(0);
  });
});

• Return an exit code

1

process.exit(0);

Image Immutability Principle (IIP)

At runtime, configurations may differ, but the image should be immutable.

We can think of an image as a class and a container as an object instance: the class is immutable, while the container is an instance of the image with different configuration parameters.

Process Disposability Principle (PDP)

In a cloud environment, we should assume that all containers are ephemeral and may be replaced by other container instances at any time.

This means that a container’s state should be stored outside the container, and containers should start and stop as quickly as possible. Generally, the smaller the container, the easier this is to achieve.

Self-Containment Principle (S-CP)

A container should include all of its dependencies at build time; in other words, a container should not have any external dependencies at runtime.

Runtime Confinement Principle (RCP)

A best practice for containers is to declare the resource configuration requirements at runtime, such as how much memory, CPU, and so on. Doing so enables the container orchestrator to schedule and manage resources more effectively.

Patterns

Many container application patterns relate to the concept of a Pod. A Pod is a concept introduced by Kubernetes to manage containers effectively; it is a collection of containers, which we can think of as a “super-container” (a term I just made up). Containers within a Pod behave as if they are running on the same machine: they share the localhost address, can communicate locally, share volumes, and so on.

Kubernetes is like an OS in the cloud, providing best practices for building cloud-native applications with containers. Let’s look at some of the common patterns.

Sidecar

The Sidecar is the most common pattern. Within the same Pod, we separate different responsibilities into different containers that together provide a complete feature to the outside world.

There are many such examples, for instance:

• The Node backend and the Redis cache in the figure above
• A web server and a log-collection service
• A web server and a service responsible for collecting server performance metrics

This is somewhat analogous to the object-oriented Composite pattern, and there are many benefits:

• Apply the Single Concern Principle: each container focuses on doing one thing well.
• Isolation: containers do not compete with each other for resources. When a secondary function (such as log collection or caching) fails or crashes, the impact on the primary function is minimized.
• Each container can be managed independently throughout its lifecycle.
• Each container can scale elastically and independently.
• Any one container can be easily replaced.

Ambassador (Proxy) Container

Similar to the object-oriented Proxy pattern, this uses a container within the Pod to provide the external access connection. As shown in the figure below, the Node backend always communicates with the outside world through the Service Discovery container.

In this way, the developers of the Node module only need to assume that all communication comes from the local machine, while the complexity of communication is delegated to the ambassador container, which handles concerns such as load balancing, security, request filtering, and, when necessary, terminating communication.

Adapter Container

People often confuse the object-oriented Proxy pattern, Bridge pattern, and Adapter pattern, because the UML diagrams look largely the same. It seems like they are just different names for the same thing. This is indeed the case—just as almost all OO patterns are derivatives of the Composite pattern, all container patterns are derivatives of the Sidecar pattern.

In the example below, if the name “Logging Adapter” did not mention “Adapter,” we would not consider it an adapter pattern.

In fact, the adapter pattern is concerned with how to uniformly expose the functionality of different containers inside the Pod through an adapter. In the figure above, it becomes clearer if we add one more container that also writes logs to the volume. The Logging Adapter adapts the logs produced by different containers through different interfaces and provides a unified access interface.

Container Chain

Similar to the OO Chain of Responsibility pattern, chaining together containers responsible for different functions in dependency order is also a common pattern.

Ready Pod

Typically, a container running as a service has a startup process during which the service is unavailable. Kubernetes provides a Readiness probe feature.

1
2
3
4
5
6

readinessProbe:
  httpGet:
    path: /
    port: 5000
  timeoutSeconds: 1
  periodSeconds: 5

Compared with the other patterns, this is more of a Kubernetes best practice.

Anti-Patterns

Mixing the Build Environment with the Runtime Environment

The image used for the production runtime environment should be as small as possible, and should avoid including leftovers from the build time.

Consider the following Dockerfile example:

1
2
3
4
5

FROM ubuntu:14.04

RUN apt-get update
RUN apt-get install gcc
RUN gcc hello.c -o /hello

The resulting image contains many things that are neither needed nor appropriate for a production environment, such as gcc and the source code hello.c. This is both insecure (directly exposing the source code) and incurs a performance overhead (an oversized image leads to slower loading).

The multi-stage builds introduced in Docker 17.05 can solve this problem.

Using Pods Directly

Avoid using Pods directly; manage Pods with a Deployment. Using a Deployment makes it easy to scale and manage Pods.

Using the latest Tag

The latest tag is meant to mark the most recent stable version. However, when creating containers, you should avoid using the latest tag in production environments as much as possible, even when the imagePullPolicy option is set to Always.

Fast-Failing Jobs

A Job is a Kubernetes container that runs only once, the opposite of a service. Avoid fast failure.

1
2
3
4
5
6
7
8
9
10
11
12
13
14

apiVersion: batch/v1
kind: Job
metadata:
  name: bad
spec:
  template:
    metadata:
      name: bad
    spec:
      restartPolicy: Never
      containers:
      - name: box
        image: busybox
        command: ["/bin/sh", "-c", "exit 1"]

If you try to create the above Job in your cluster, you might encounter the following status.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25

$ kubectl describe jobs 
Name:   bad
Namespace:  default
Image(s): busybox
Selector: controller-uid=18a6678e-11d1-11e7-8169-525400c83acf
Parallelism:  1
Completions:  1
Start Time: Sat, 25 Mar 2017 20:05:41 -0700
Labels:   controller-uid=18a6678e-11d1-11e7-8169-525400c83acf
    job-name=bad
Pods Statuses:  1 Running / 0 Succeeded / 24 Failed
No volumes.
Events:
  FirstSeen LastSeen  Count From      SubObjectPath Type    Reason      Message
  --------- --------  ----- ----      ------------- --------  ------      -------
  1m    1m    1 {job-controller }     Normal    SuccessfulCreate  Created pod: bad-fws8g
  1m    1m    1 {job-controller }     Normal    SuccessfulCreate  Created pod: bad-321pk
  1m    1m    1 {job-controller }     Normal    SuccessfulCreate  Created pod: bad-2pxq1
  1m    1m    1 {job-controller }     Normal    SuccessfulCreate  Created pod: bad-kl2tj
  1m    1m    1 {job-controller }     Normal    SuccessfulCreate  Created pod: bad-wfw8q
  1m    1m    1 {job-controller }     Normal    SuccessfulCreate  Created pod: bad-lz0hq
  1m    1m    1 {job-controller }     Normal    SuccessfulCreate  Created pod: bad-0dck0
  1m    1m    1 {job-controller }     Normal    SuccessfulCreate  Created pod: bad-0lm8k
  1m    1m    1 {job-controller }     Normal    SuccessfulCreate  Created pod: bad-q6ctf
  1m    1s    16  {job-controller }     Normal    SuccessfulCreate  (events with common reason combined)

Because the Job fails fast, Kubernetes considers the Job to have failed to start successfully and tries to create new containers to recover from this failure, causing the cluster to create a large number of containers in a short period of time, which can consume a significant amount of computing resources.

Use .spec.activeDeadlineSeconds in the Spec to avoid this problem. This parameter defines how long to wait before retrying a failed Job.

Source: https://my.oschina.net/taogang/blog/1809904

[SOLID]: https://zh.wikipedia.org/wiki/SOLID_(%E9%9D%A2%E5%90%91%E5%AF%B9%E8%B1%A1%E8%AE%BE%E8%AE%A1)“SOLID”

In my view, architects have always been a talent pool for future CTOs, because the range of skills required is so broad.

Doing architecture, in its simplest understanding, boils down to one sentence: figuring out how to solve problems under various constraints.

Those constraints are factors like performance, stability, development efficiency, and maintainability.

• An application like Baidu Tieba might see hundreds of millions of visits and tens of millions — or even hundreds of millions — of writes per day. Performance clearly has to come first, and you may have to trade some development efficiency for performance gains.

• In a banking scenario, user experience and access latency matter less, but data security and consistency are paramount. In that case, security and stability come first, with performance considered later.

Making tradeoffs under constraints means making a lot of choices. And to make choices, you first have to know what the options are.

For performance and security to mean anything beyond the words themselves, you have to know, in concrete technical terms, what solutions are actually available.

• For example, the Java ecosystem, the PHP ecosystem, the C ecosystem, and Python/Node.js/Golang each have their own strengths and weaknesses; you need hands-on development experience with them to make the right choice. Hearsay gives you no standing to decide.

• Although MySQL is by far the most widely used database today, Oracle and PostgreSQL have their own advantages.

• Almost no modern project avoids big data altogether, so you need at least some understanding of big-data algorithms and some hands-on experience with big-data platforms.

• Running an entire project involves a great many other concerns: how source code is managed, how releases are deployed, how testing keeps the bug rate down, system monitoring, server provisioning, canary releases, and so on.

Don’t listen to people who make “architect” sound lofty and rarefied, as if it were purely a designer’s job — system design, software design, and so on. That’s just second-hand romanticizing.

No internet company will hire you purely to do design, because without exception every internet company’s leadership needs the implementation of features and the realization of strategic and tactical ideas.

Every large-scale system architecture is iterated step by step in response to the problems it faces. There is no scenario in which someone gets to design a brilliant system all in one go (even with a head start of a while), because the world changes too fast. If the project isn’t implemented quickly, it may die tomorrow — who has the leisure to design for years into the future?

So the single most critical thing for an architect is the ability to steer the entire project and keep it running efficiently.

Excellent Coding Ability

If you want to become an architect, you first have to be an excellent programmer. So what makes an excellent programmer?

Just writing code without thinking or learning obviously won’t do.

Concretely, you have to deeply master all kinds of data structures, design patterns, computer networking, operating systems, and common architectural patterns. These get mentioned constantly, but I suspect very few people truly understand them in depth.

I include myself: when I first studied design patterns, I felt within a month or so that I understood all of them. But every time I revisited the topic, or came across exceptionally well-written code, and went back to review this material, I always found something new and reached a deeper level of understanding.

And understanding is only the beginning. The real key is fully integrating these ideas into your own code.

Writing code is itself shot through with the feel of architectural design. In fact, I’d argue that when a programmer writes code it’s called “coding,” but when an architect writes code it’s called “architectural design.”

That’s because the two consider problems from completely different angles. A programmer mainly thinks about how to implement a feature, while an excellent programmer also thinks about things like performance, readability, and maintainability.

For an architect, those concerns are mandatory, and the dimensions considered are usually even broader.

So don’t imagine you can skip “excellent programmer” and jump straight to “architect” in one step. It’s unrealistic.

Depth in Certain Relevant Domains

I just talked about the breadth of technology. But if you know a little about everything yet excel at nothing — if you’re not genuinely expert in anything — then you’ll remain just a programmer.

So which domains count as key domains?

From here onward, architects essentially diverge according to their business direction.

For example, an architect in the financial domain may need financial knowledge.

In the big-data domain, deep knowledge of Hadoop, Spark, Hive, and similar technologies may be required.

In the high-concurrency domain, deeper expertise in system-wide performance optimization and distributed-system design may be needed.

Technical Insight

“Technical insight” is a term I’m borrowing from the book How Google Works (originally 《重新定义公司》). A more intuitive phrasing would be “technical foresight and vision.”

A few examples, with the benefit of hindsight:

1. If JD.com had not chosen the Windows platform back then, it might have developed far better than it has today.

2. If it weren’t for the short-sightedness of a certain Baidu leader, who was always a few beats behind the market, Baidu wouldn’t now be left far behind by AT.

3. ……

This shouldn’t feel abstract. If you’re currently an architect at a startup, a seemingly correct decision you make today could directly cause major losses for the company in the future — or even its collapse.

Management Ability

Few architects lead neither projects nor people, so management ability is certainly a must.

But management is a huge topic in its own right, so I won’t expand on it here.

Looking back, what I’ve written is all fairly directional.

But given the particular nature of the architect role, it’s genuinely hard to lay out a concrete path such that, if you just follow it, you’ll become an excellent architect.

There are, however, some principled approaches.

As an architect, so-called design ability is not really the key. There are few opportunities to design a project entirely from scratch, and in most cases you can simply combine other people’s design solutions, weighed against the situation at hand.

That’s why, once you’ve read enough architect-related posts, you realize that so-called distributed architectures and large-site architectures are basically the same handful of patterns over and over. As a result, anyone can come out and mouth a few sentences about “architecture.”

So what is the key? It’s the ability to steer a project, and to solve concrete problems as they arise.

And developing project-steering ability and concrete problem-solving ability sometimes requires more than just the projects at your company.

In company projects you’re usually only one member of a team, doing one specific piece of work — frontend JS, an app, backend business logic, etc. You generally can’t see how the project as a whole runs. Even if you’re lucky and the project lead has the whole thing under control and is willing to explain it all to you, you still haven’t built those parts with your own hands, and listening to someone describe them is unlikely to give you a deep understanding.

So what should you do? Carve out time to build an entirely new project of your own — for example a BBS site, or an app with a back end. The site or app itself doesn’t matter; what matters is that you develop it yourself, get the deployment system working, get the monitoring system working, get the release system working, get the testing system working, and so on.

Treat your own project exactly like an official product at a real company.

After a few rounds of this, you’ll find your sense of the entire project dramatically sharpened. You’ll no longer be fuzzy about everything except the part you personally own.

Source: https://zhuanlan.zhihu.com/p/27979747

1
2
3
4
5
6
7

vim /etc/sysctl.conf

# Add the configuration
net.ipv6.conf.all.disable_ipv6 = 0
net.ipv6.conf.default.disable_ipv6 = 0
net.ipv6.conf.lo.disable_ipv6 = 0

Verify that it took effect

1
2
3
4
5
6
7
8
9
10
11
12

ifconfig

# Output
eth1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 114.55.127.xxx  netmask 255.255.252.0  broadcast 114.55.119.255
        inet6 fe80::219:3eff:fexx:32ec  prefixlen 64  scopeid 0x20<link>
        ether 00:16:3e:01:49:37  txqueuelen 1000  (Ethernet)
        RX packets 68348  bytes 41664492 (39.7 MiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 18859  bytes 3632548 (3.4 MiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

fe80::219:3eff:fexx:32ec is the IPv6 address.

1
2
3
4

$ sudo apt-key adv --keyserver hkp://keyserver.ubuntu.com:80 --recv 0C49F3730359A14518585931BC711F9BA15703C6


echo "deb [ arch=amd64,arm64 ] http://repo.mongodb.org/apt/ubuntu "$(lsb_release -sc)"/mongodb-org/3.4 multiverse" | sudo tee /etc/apt/sources.list.d/mongodb-3.4.list

Install MongoDB

1
2

apt-get update
apt-get install mongodb-org -y

Start the Service

1
2

service mongod start
service mongod stop

Create a Username and Password

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

# Edit the configuration file
vim /ect/mongod.conf

security:  
authorization: "enabled"

# Restart the service
service mongod stop
service mongod start

# Enter the database
mongo
> use admin
> db.createUser({user:"user_test",pwd:"pwd_test",roles:["root"]}) # Create the account  
> db.auth("user_test","pwd_test") # You can now log in

This article introduces the essential software used on Mac OS.

Software

Command Line Tool

1

xcode-select --install

Homebrew

Homebrew

1

/usr/bin/ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)"

Oh My Zsh

Oh My Zsh

1
2
3

brew install zsh

sh -c "$(curl -fsSL https://raw.githubusercontent.com/robbyrussell/oh-my-zsh/master/tools/install.sh)"

Prezto

Prezto

1
2
3
4
5
6
7
8
9
10
11
12
13
14

# Launch Zsh:
zsh

#Clone the repository:
git clone --recursive https://github.com/sorin-ionescu/prezto.git "${ZDOTDIR:-$HOME}/.zprezto"

#Create a new Zsh configuration by copying the Zsh configuration files provided:
setopt EXTENDED_GLOB
for rcfile in "${ZDOTDIR:-$HOME}"/.zprezto/runcoms/^README.md(.N); do
  ln -s "$rcfile" "${ZDOTDIR:-$HOME}/.${rcfile:t}"
done

# Set Zsh as your default shell:
chsh -s /bin/zsh

Brew Cask

Homebrew Cask

1
2

brew tap phinze/cask
brew install brew-cask

TotalTerminal

1

brew cask install totalterminal

LaunchRocket

1

brew cask install launchrocket

shadowssocks

1

https://github.com/shadowsocks/shadowsocks-iOS/releases

alfred 3

1

brew cask install alfred

moom

1

brew cask install moom

1. Java SDK

   1	aptitude install openjdk-8-jdk

2. Install the extraction tool

   1 2	# Install the extraction tool aptitude install unzip

3. Download and install DynamoDB

   1 2 3 4 5 6 7 8 9 10 11

   # Download the archive wget http://dynamodb-local.s3-website-us-west-2.amazonaws.com/dynamodb_local_latest.zip # Extract unzip ./dynamodb_local_latest.zip # Start java -Djava.library.path=./DynamoDBLocal_lib -jar DynamoDBLocal.jar -sharedDb # View help java -Djava.library.path=./DynamoDBLocal_lib -jar DynamoDBLocal.jar -help

4. javascript shell

   http://127.0.0.1:8000/shell/

As the domestic “wall” grows ever “taller”, mastering a convenient, fast, and affordable way to “leap over” it has become a necessity. Below we introduce Shadowsocks, a lightweight, cross-platform, open-source tool that is very easy to install and configure.

Installation

Prerequisites

• A VPS
  You can use the SFO region of digitalocean
• A Python environment

Server Installation

1. Install via pip

   • Install pip

     1	apt-get install python-pip

   • Install shadowsocks

     1	pip install shadowsocks

Configuration

1

vim /etc/shadowsocks.json

Add the following content

1
2
3
4
5
6
7
8
9
10
11

{
    "server": "my_server_ip",               # server IP
    "server_port": 8000,                    # listening port
    "local_address": "x.x.x.x",             # server local address
    "local_port": 1080,                     # server local port
    "password": "mypassword",               # connection password
    "timeout": 300,                         # connection timeout
    "method": "rc4-md5"
    "fast_open": true                       # whether to enable TCP_FASTOPEN (requires kernel support)
    "workers": 5                            # number of worker processes
}

System Optimization

Confirm the kernel version is 3.7.1 or above

1
2
3

uname -r

# 4.4.0-45-generic

1. Maximum number of file descriptors

   • Before each Shadowsocks launch

     1	ulimit -SHn 51200

   • Take effect at system boot

     1 2 3 4 5 6 7

     vim /etc/security/limits.conf # Add * soft nofile 51200 * hard nofile 51200 # First column: user or group # Second column: hard = hard limit, soft = soft limit. Generally soft is smaller than hard; exceeding soft triggers a warning, while hard is the ceiling # Third column: nofile = number of open files

     1 2 3

     vim /etc/pam.d/common-session # Add the line session required pam_limits.so

     1 2 3

     vim /etc/profile # Append at the end of the file ulimit -SHn 51200

2. Tune kernel parameters

   1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30

   vim /etc/sysctl.conf # Add the configuration fs.file-max = 51200 # max open files net.core.rmem_max = 67108864 # max read buffer net.core.wmem_max = 67108864 # max write buffer net.core.netdev_max_backlog = 250000 # max processor input queue net.core.somaxconn = 4096 # max backlog net.ipv4.tcp_syncookies = 1 # resist SYN flood attacks net.ipv4.tcp_tw_reuse = 1 # reuse timewait sockets when safe net.ipv4.tcp_tw_recycle = 0 # turn off fast timewait sockets recycling net.ipv4.tcp_fin_timeout = 30 # short FIN timeout net.ipv4.tcp_keepalive_time = 1200 # short keepalive time net.ipv4.ip_local_port_range = 10000 65000 # outbound port range net.ipv4.tcp_max_syn_backlog = 8192 # max SYN backlog net.ipv4.tcp_max_tw_buckets = 5000 # max timewait sockets held by system simultaneously net.ipv4.tcp_rmem = 4096 87380 67108864 # TCP receive buffer net.ipv4.tcp_wmem = 4096 65536 67108864 # TCP write buffer net.ipv4.tcp_mtu_probing = 1 # turn on path MTU discovery net.ipv4.tcp_fastopen = 3 # enable TCP_FASTOPEN net.ipv4.tcp_congestion_control = hybla # Apply the configuration sysctl -p

   • TCP_FASTOPEN
     The Linux kernel version on both the server and client sides must be newer than 3.7.1

     1 2 3 4

     # Check whether it is in effect sysctl net.ipv4.tcp_fastopen # net.ipv4.tcp_fastopen = 3

   • TCP congestion control algorithms
     Linux ships with several TCP congestion control algorithms.

     1. reno is the most basic congestion control algorithm and the experimental prototype of the TCP protocol.
     2. bic suits links with high RTT but extremely rare packet loss, such as the route between North America and Europe; it was the default algorithm for Linux kernels from 2.6.8 to 2.6.18.
     3. cubic is a modified version of bic and covers a broader range of scenarios than bic; it is the default algorithm for Linux kernels after 2.6.19.
     4. hybla suits networks with high latency and high packet loss rates, such as satellite links — and equally the route between China and the United States.

     1 2 3 4

     # List algorithms supported by the system sysctl net.ipv4.tcp_available_congestion_control # net.ipv4.tcp_available_congestion_control = hybla cubic reno

Launch

• Launch directly

1

ssserver -p 8000 -k password -m rc4-md5 -d {start | stop}

• Launch from a configuration file

1

ssserver -c /etc/shadowsocks.json -d {start | stop}

Summary

With the digitalocean SFO2 region at 300+ ms latency, you can smoothly stream 1080P video on YouTube (Hunan Telecom).

Yii

Yii is a high-performance PHP framework suitable for developing Web 2.0 applications.
Yii ships with a rich set of features, including MVC, DAO/ActiveRecord, I18N/L10N, caching, authentication and role-based access control, scaffolding, testing, and more, which can significantly shorten development time.

Creation

Prerequisites

• PHP runtime environment
• Composer environment

  • Mac OS X

    1
    brew install composer
    

  • Ubuntu

    1 2 3 4 5 6 7 8

    # Download curl -sS https://getcomposer.org/installer | php -d detect_unicode=Off # Make it global mv composer.phar /usr/local/bin/composer # Permissions chmod a+x /usr/local/bin/composer # Update composer self-update

Installation

1. Install via Composer

   Install the composer-asset-plugin.

   1 2 3 4

   # Switch to the China mirror (http://pkg.phpcomposer.com/) composer config -g repo.packagist composer https://packagist.phpcomposer.com composer global require "fxp/composer-asset-plugin:^1.2.0"

   Install the basic edition.

   1	composer create-project yiisoft/yii2-app-basic xxx

   Install the advanced edition.

   1	composer create-project yiisoft/yii2-app-advanced xxx

2. Download and install

   Basic edition
   Advanced edition

Tips

1

The zip extension and unzip command are both missing, skipping.

Solution

1

apt-get install php7.0-zip

1
2

codeception/base 2.2.3 requires phpunit/phpunit >4.8.20 <5.5 -> satisfiable by phpunit/phpunit
phpunit/phpunit 5.6.2 requires ext-dom * -> the requested PHP extension dom is missing from your system.

Solution

1

apt-get install php7.0-xml

Siege is a load testing and benchmarking tool for Linux, designed for web developers to evaluate how well an application holds up under stress. It can be configured to perform concurrent access by multiple users against a web site, recording the response time of every request for each user, and repeating this under a given number of concurrent users. It supports multiple connections as well as GET and POST requests.

Installation

• Mac OSX

  1	brew install siege

• Ubuntu

  1	aptitude install siege

Parameters

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

-c:  Simulate N concurrent users accessing the target

-r:  Repeat the test run N times

-t:  Duration of the test run. The default unit is minutes, e.g. 5s (5 seconds) or 5 (5 minutes).
# -r and -t are generally not used together

-f:  The URL list for the workload

-i:  Randomly access URLs from the url.txt file specified by -f, in order to simulate real access patterns (randomness)

-b:  Run a stress test with no delay between requests (delay=0)

-A:  Specify the User-Agent for the requests
-H:  Specify a Header for the requests
-T:  Specify the Content-Type for the requests

siege -c 200 -r 100 http://www.google.com
siege -c 200 -r 100 -f urls.txt
siege -c 200 -r 100 -f urls.txt -i
siege -c 200 -r 100 -f urls.txt -i -b delay=0, a more accurate stress test rather than a functional test
siege -H "Content-Type:application/json" -c 200 -r 100 -f urls.txt -i -b

Result Explanation

1
2
3
4
5
6
7
8
9
10
11
12

Transactions:            20 hits            # Total number of tests performed
Availability:            100.00 %           # Success ratio
Elapsed time:            1.52 secs          # Total time elapsed
Data transferred:            0.80 MB            # Total data transferred
Response time:            0.14 secs          # Response time
Transaction rate:            13.16 trans/sec    # Requests processed per second
Throughput:            0.52 MB/sec        # Throughput rate
Concurrency:            1.82               # Highest concurrency
Successful transactions:            20                 # Number of successful requests
Failed transactions:                0                  # Number of failed requests
Longest transaction:                0.51               # Longest time for a single transaction
Shortest transaction:               0.05               # Shortest time for a single transaction

Tips

When sending a POST request, the URL format is: http://www.xxxx.com/ POST p1=v1&p2=v2

If the URL contains spaces or non-ASCII characters, it must be encoded first.

1. Prefer static when possible

   If a function can be made static, prefer to make it static.
   The difference mainly shows up in memory handling: static methods allocate memory when the program starts, whereas instance methods allocate memory only when the object is instantiated.
   Static methods can be called directly, while instance methods require you to first create an instance and then call through it.

Too many static methods will consume memory.

1. echo VS print

   echo is faster than print, because echo has no return value while print returns an integer.

   When echoing large strings, the corresponding configuration needs to be done on the server.

2. echo multiple strings

   When echo-ing multiple strings, use , instead of . to join them.

3. @ error suppression

   Using @ to suppress errors slows down the script. In particular, avoid using @ inside loops.

4. $row[‘id’] & $row[id] & $row[1]

   'id' looks up the key 'id' directly. Without quotes, a variable or constant is parsed by first determining its type and then resolving the value.

5. isset() & empty()

   isset() tests whether a variable has been assigned.
   empty() tests whether an already-assigned variable is empty. Referencing a variable that hasn’t been assigned is allowed but produces a notice.

   If a variable is assigned an empty value $t = ""; $t = 0; $t = false;, both empty($t) and isset($t) return true.
   To destroy a variable, use unset($t) or $t = NULL.

6. Confirm the maximum count before looping

   Determine the maximum count before entering a for loop; don’t recompute the maximum on every iteration.

   1 2 3 4 5 6 7 8

   // Don't do this for ($i=0;$i<=count($array);$i++){ } // Do this instead $len = count($array); for ($i=0;$i<=$len;$i++){ }

7. include() & include_once() & require() & require_once()

   All four load a file. The _once variants first check whether the file has already been loaded, to avoid loading it twice.
   The main differences are:

   • Error handling
     • require() throws a fatal error and halts the script if the file doesn’t exist.
     • include() throws a warning but the script continues if the file doesn’t exist.
   • Performance
     • require() processes the file only once (in effect, the file’s content replaces the require() statement).
     • include() reads and evaluates the file on every execution.
       If code containing one of these directives may run multiple times, require() is more efficient.
   • Flexibility
     • require() is usually placed at the very top of a script; the specified file is loaded before execution, becoming part of the script.
     • include() is usually placed inside control-flow blocks. The file is loaded only when execution reaches it. This can simplify the runtime flow.

Use full paths when including files, to reduce the time spent resolving paths.

1. ‘ ‘ & “ “

   PHP allows both single and double quotes to delimit string variables.
   " " first reads the string contents, then looks for variables inside it and interpolates their values.

2. Don’t copy variables carelessly

   Copying one variable into another doubles the memory consumption.

3. if else & switch case

   A switch/case is better than a long chain of if/else if statements, and the code is easier to read and maintain.

4. Not everything has to be object-oriented

   Object orientation often carries significant overhead; every method call and object instantiation consumes memory.

5. Don’t split methods too finely

   Every method call consumes memory.

6. Prefer PHP’s built-in functions where possible.

7. Don’t declare variables inside loops, especially large ones: objects.

8. Destroy variables to release memory, especially large arrays.

9. Use string functions instead of regular expressions.

10. split is faster than explode.