发表于 | 分类于

PSR 是 PHP Standard Recommendations 的简写，由 PHP FIG 组织制定的 PHP 规范，是 PHP 开发的实践标准。

目前已表决通过了 6 套标准，已经得到大部分 PHP 框架的支持和认可。

PSR-1 基础编码规范

  • PHP 代码文件 必须 以 <?php 或 <?= 标签开始；
  • PHP 代码文件 必须 以 不带 BOM 的 UTF-8 编码；
  • PHP 代码中 应该 只定义类、函数、常量等声明，或其他会产生 副作用 的操作（如：生成文件输出以及修改 .ini 配置文件等），二者只能选其一；
  • 命名空间以及类 必须 符合 PSR 的自动加载规范：PSR-4 中的一个；
  • 类的命名 必须 遵循 StudlyCaps 大写开头的驼峰命名规范；
  • 类中的常量所有字母都 必须 大写，单词间用下划线分隔；
  • 方法名称 必须 符合 camelCase 式的小写开头驼峰命名规范。

PSR-2 编码风格规范

  • 代码 必须 遵循 PSR-1 中的编码规范 。
  • 代码 必须 使用 4 个空格符而不是「Tab 键」进行缩进。
  • 每行的字符数 应该 软性保持在 80 个之内，理论上 一定不可 多于 120 个，但 一定不可 有硬性限制。
  • 每个 namespace 命名空间声明语句和 use 声明语句块后面，必须 插入一个空白行。
  • 类的开始花括号（{） 必须 写在类声明后自成一行，结束花括号（}）也 必须 写在类主体后自成一行。
  • 方法的开始花括号（{） 必须 写在函数声明后自成一行，结束花括号（}）也 必须 写在函数主体后自成一行。
  • 类的属性和方法 必须 添加访问修饰符（private、protected 以及 public），abstract 以及 final 必须 声明在访问修饰符之前，而 static 必须 声明在访问修饰符之后。
  • 控制结构的关键字后 必须 要有一个空格符，而调用方法或函数时则 一定不可 有。
  • 控制结构的开始花括号（{） 必须 写在声明的同一行，而结束花括号（}） 必须 写在主体后自成一行。
  • 控制结构的开始左括号后和结束右括号前，都 一定不可 有空格符。

PSR-3 日志接口规范

  • 日志接口提供了8个级别的日志方法包含（debug， info,notice,warning,error,critical,alert,emergency）,log方法接受日志级别作为第一个参数
  • 每一个方法都接受一个字符串作为一个描述，或者是实现了__toString()方法的类
  • 每一个方法都接受一个数组类型的上下文数据
  • Psr\Log\AbstractLogger是实现日志接口的好的方式，Psr\Log\LoggerTrait仅仅需要实现log方法，Psr\Log\NullLogger空日志接口，Psr\Log\LoggerAwareInterface可以wrapper一个logger,Psr\Log\LogLevel 包含8个日志级别

PSR-4 自动加载规范

  • 适用于类、接口、traits和其他相似的结构
  • 一个完全限定的类名具备如下结构 \NamespaceName\SubNamespaceName*\ClassName, 即包含顶级的命名空间 as a vendor namespace ,或许包含一个或者多个子命名空间，必须包含一个类名，下划线不再具有任何意义，类名大小写敏感。自动加载不能抛出异常，不报错，不返回任何值

PSR-7 HTTP 消息接口规范

  • 包含Psr\Http\Message\RequestInterface和Psr\Http\Message\ResponseInterface，这两个接口都是扩展Psr\Http\Message\MessageInterface而来
  • http头大小写不敏感

发表于 | 分类于

SAPI（Server Application Programming Interface）服务器应用程序编程接口，它提供了PHP与其他应用交互的接口。PHP脚本执行有很多方式：Web服务器/命令行下/嵌入在其他程序中等等。

PHP提供了一个常量PHP_SAPI和一个方法php_sapi_name()来判断当前PHP运行环境，以下是常见运行环境：

CLI

cli命令行接口, 在命令行下执行PHP脚本, 内置web服务器，如果请求未指定执行哪个PHP脚本，则默认执行目录下的index.php 或index.html，如果这两个文件都不存在则返回404

CGI

CGI 即通用网关接口（Commom Gateway Interface），它把网页和WEB服务器中的执行程序连接起来，把从HTML接收的指令传递给服务器的执行程序，再把服务器执行程序的结果返还给HTML页。CGI的跨平台性能极佳，几乎可以在任何操作系统上实现。

CGI方式在遇到连接请求先要创建CGI的子进程，激活一个CGI进程，然后处理请求，处理完后结束这个子进程。这就是fork-and-execute模式。所以用cgi方式的服务器有多少连接请求就会有多少cgi子进程，子进程反复加载是CGI性能低下的主要原因。都会当用户请求数量非常多时，会大量挤占系统的资源如内存，CPU时间等，造成效能低下。

FastCGI

fast-cgi 是 CGI的升级版本，FastCGI可以看成是一个常驻型的CGI，它可以一直执行着，只要激活后，不会每次都要花费时间去fork一次。PHP使用PHP-FPM（FastCGI Process Manager），全称PHP FastCGI 进程管理器进行管理。

FastCGI的工作原理：

  1. Web Server启动时载入FastCGI进程管理器
  2. FastCGI进程管理器自身初始化，启动多个CGI解释器（可见多个php-cgi）并等待来自Web Server的连接
  3. 当客户端请求到达Web Server是，FastCGI进程管理器选择并连接到一个CGI解释器。Web Server将CGI环境变量和标准输入发送到FastCGI子进程php-cgi
  4. FastCGI子进程完成处理后将标准输出和错误信息从同一连接返回Web Server。当FastCGI子进程关闭连接是，请求便告知处理完成。FastCGI子进程接着等待并处理来自FastCGI继承管理器的下一个连接。在CGI模式中，php-cgi在此便退出了。

CGI每个Web请求PHP都必须重新解析php.ini、重新载入全部扩展并重出始化全部数据结构。而使用FastCGI，所有这些都只在进程启动时发生一次。

Apache模块的DLL

该运行模式是我们以前在windows环境下使用apache服务器经常使用的，而在模块化(DLL)中，PHP是与Web服务器一起启动并运行的。

发表于 | 分类于

LRU 就是一种缓存淘汰策略。计算机的缓存容量有限，如果缓存满了就要删除一些内容，给新内容腾位置。但问题是，删除哪些内容呢？我们肯定希望删掉那些没什么用的缓存，而把有用的数据继续留在缓存里，方便之后继续使用。那么，什么样的数据，我们判定为「有用的」的数据呢？

LRU 缓存淘汰算法就是一种常用策略。LRU 的全称是 Least Recently Used，也就是说我们认为最近使用过的数据应该是是「有用的」，很久都没用过的数据应该是无用的，缓存满了就优先删那些很久没用过的数据。

我们使用HashMap来存放数据，再使用双向链表来维护最近最少使用的顺序，双向链表从头到尾依次最近最少使用的到最近最多使用的

发表于 | 分类于

Composer

Composer是 用PHP开发的用来管理项目依赖的工具，当你在项目中声明了依赖关系后，composer可以自动帮你下载和安装这些依赖库，并实现自动加载代码。

定义一个composer.json:

1
2
3
4
5
6
{
	"name": "gitlib/composer",
	"require":{
		"predis/predis":"1.1.1"
	}
}

输入命令 composer install，composer会帮我们自动下载predis库，依赖库会默认放在项目的vendor目录下。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
├── composer.json
├── composer.lock
├── index.php
└── vendor
    ├── autoload.php
    ├── composer
    │   ├── ClassLoader.php
    │   ├── LICENSE
    │   ├── autoload_classmap.php
    │   ├── autoload_namespaces.php
    │   ├── autoload_psr4.php
    │   ├── autoload_real.php
    │   ├── autoload_static.php
    │   └── installed.json
    └── predis
        └── predis

composer不仅仅帮我们处理依赖，还帮我们实现了自动加载。在vendor目录下有一个autoload.php, 只要在我们的项目中引入这个文件就可以自动加载依赖库。

1
2
3
4
5
6
7
8
<?php

require 'vendor/autoload.php';

$client = new Predis\Client();
$client->set('foo', 'bar');
$value = $client->get('foo');
echo $value;

可以看到Predis库完全不需要我们手动去加载，只需要require 'vendor/autoload.php'，composer的自动加载机制会帮我们找到对应的文件并加载。

对于依赖库，composer帮我们处理好了自动加载, 那对于其他的类库，如何实现自动加载呢？

composer支持四种自动加载的方式：Files/Classmap/PSR-0/ PSR-4, 其中PSR-4是当前推荐的加载方式。

Files

Files 是最简单的加载方式，这种方式不管加载的文件是否用到始终都会加载，而不是按需加载, 修改项目根目下的composer.json, 加入 “autoload” 项：

1
2
3
4
5
6
7
8
9
{
	"name": "gitlib/composer",
	"require":{
		"predis/predis":"1.1.1"
	},
	"autoload":{
		"files":["Controller/User.php"]
	}
}

files键对应的值是一个数组，数组元素是文件的路径，路径是相对于应用的根目录。加上上述内容后，运行命令：

composer dump-autoload

让composer重建自动加载的信息，composer会把配置值写入与 Files加载方式对应的 verndor\composer\autoload_files.php配置文件中：

1
2
3
4
5
6
7
8
9
10
<?php

// autoload_files.php @generated by Composer

$vendorDir = dirname(dirname(__FILE__));
$baseDir = dirname($vendorDir);

return array(
    '7efd69bb86214589340b40039fd363f7' => $baseDir . '/Controller/User.php',
);

现在就可以在代码中里调用User类了。

1
2
3
4
5
6
7
8
<?php

require 'vendor/autoload.php';

$client = new Predis\Client();

$user = new \Controller\User();
$user->login();

Classmap

classmap引用的所有组合，都会在 install/update 过程中生成，并存储到vendor/composer/autoload_classmap.php 文件中。这个 map 是经过扫描指定目录（同样支持直接精确到文件）中所有的 .php 和 .inc 文件里内置的类而得到的。

1
2
3
4
5
6
7
8
9
{
	"name": "gitlib/composer",
	"require":{
		"predis/predis":"1.1.1"
	},
	"autoload":{
		"classmap":["Controller"]
	}
}

Composer会扫描Controller目录下的所有.php和.inc文件，存储到vendor/composer/autoload_classmap.php文件中：

1
2
3
4
5
6
7
8
9
10
<?php

// autoload_classmap.php @generated by Composer

$vendorDir = dirname(dirname(__FILE__));
$baseDir = dirname($vendorDir);

return array(
    'Controller\\User' => $baseDir . '/Controller/User.php',
);

PSR-0

PSR-0自动加载规范是已经废弃的标准, 不再做说明。

PSR-4

PSR-4是Composer推荐使用的一种方式(关于PSR规范可参考：PHP标准规范PSR)，因为它更易使用并能带来更简洁的目录结构。对于上面的Controller目录我们先改名src:

1
2
3
4
5
6
7
8
9
10
├── composer.json
├── composer.json.bk
├── composer.lock
├── index.php
├── src
│   └── User.php
└── vendor
    ├── autoload.php
    ├── composer
    └── predis

在composer.json中我们将Controller命名空间和src关联起来：

1
2
3
4
5
6
7
8
9
10
11
{
	"name": "gitlib/composer",
	"require":{
		"predis/predis":"1.1.1"
	},
	"autoload":{
		"psr-4": {
			"Controller\\":"src/"
		}
	}
}

PSR-4 的命名空间前缀也必须以 \\ 结尾，以避免类似前缀间的冲突。

psr-4中的key和value定义了namespace以及其对应的目录映射。按照PSR-4的规则，当试图自动加载”Controller\User”类的使用，会去寻找”src/User.php”这个文件，此时Controller并不会出现在文件路径中。

自动加载原理

下面我们通过源码分析composer是如何实现自动加载功能。

入口

1
2
3
<?php

require 'vendor/autoload.php';

我们通过require ‘vendor/autoload.php实现自动加载，vendor/autoloaad.php文件引用composer/autoload_real.php。

1
2
3
4
5
6
7
<?php

// autoload.php @generated by Composer

require_once __DIR__ . '/composer/autoload_real.php';

return ComposerAutoloaderInitb84761f57e62a6a534584b91ca213591::getLoader();

autoload_real

autoload_real.php是自动加载引导类，程序主要调用了引导类的静态方法getLoader()。

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
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
<?php

// autoload_real.php @generated by Composer

class ComposerAutoloaderInitb84761f57e62a6a534584b91ca213591
{
    private static $loader;

    public static function loadClassLoader($class)
    {
        if ('Composer\Autoload\ClassLoader' === $class) {
            require __DIR__ . '/ClassLoader.php';
        }
    }

    public static function getLoader()
    {
        // 返回Composer\Autoload\ClassLoader单例
        if (null !== self::$loader) {
            return self::$loader;
        }

        // 调用spl_autoload_register加载\Composer\Autoload\ClassLoader
        spl_autoload_register(array('ComposerAutoloaderInitb84761f57e62a6a534584b91ca213591', 'loadClassLoader'), true, true);
        // 实例化\Composer\Autoload\ClassLoader类
        self::$loader = $loader = new \Composer\Autoload\ClassLoader();
        spl_autoload_unregister(array('ComposerAutoloaderInitb84761f57e62a6a534584b91ca213591', 'loadClassLoader'));

        // 静态初始化只支持 PHP5.6 以上版本并且不支持 HHVM 虚拟机
        $useStaticLoader = PHP_VERSION_ID >= 50600 && !defined('HHVM_VERSION') && (!function_exists('zend_loader_file_encoded') || !zend_loader_file_encoded());
        if ($useStaticLoader) {
            //  使用 autoload_static 进行静态初始化
            require_once __DIR__ . '/autoload_static.php';
            call_user_func(\Composer\Autoload\ComposerStaticInitb84761f57e62a6a534584b91ca213591::getInitializer($loader));
        } else {
            // 如果PHP版本低于 5.6 或者使用 HHVM 虚拟机环境，那么就要使用核心类的接口进行初始化
            // PSR0 标准
            $map = require __DIR__ . '/autoload_namespaces.php';
            foreach ($map as $namespace => $path) {
                $loader->set($namespace, $path);
            }

            // PSR4 标准
            $map = require __DIR__ . '/autoload_psr4.php';
            foreach ($map as $namespace => $path) {
                $loader->setPsr4($namespace, $path);
            }   

            // classmap
            $classMap = require __DIR__ . '/autoload_classmap.php';
            if ($classMap) {
                $loader->addClassMap($classMap);
            }
        }

        $loader->register(true);

        // files
        if ($useStaticLoader) {
            $includeFiles = Composer\Autoload\ComposerStaticInitb84761f57e62a6a534584b91ca213591::$files;
        } else {
            $includeFiles = require __DIR__ . '/autoload_files.php';
        }
        // files定义的文件，直接require就行了
        foreach ($includeFiles as $fileIdentifier => $file) {
            composerRequireb84761f57e62a6a534584b91ca213591($fileIdentifier, $file);
        }

        return $loader;
    }
}

autoload_static

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
31
32
33
34
35
36
37
38
39
40
41
42
43
<?php

// autoload_static.php @generated by Composer

namespace Composer\Autoload;

class ComposerStaticInitb84761f57e62a6a534584b91ca213591
{
    public static $files = array (
        '7efd69bb86214589340b40039fd363f7' => __DIR__ . '/../..' . '/Controller/User.php',
    );

    public static $prefixLengthsPsr4 = array (
        'P' => 
        array (
            'Predis\\' => 7,
        ),
        'C' => 
        array (
            'Controller\\' => 11,
        ),
    );

    public static $prefixDirsPsr4 = array (
        'Predis\\' => 
        array (
            0 => __DIR__ . '/..' . '/predis/predis/src',
        ),
        'Controller\\' => 
        array (
            0 => __DIR__ . '/../..' . '/src',
        ),
    );

    public static function getInitializer(ClassLoader $loader)
    {
        return \Closure::bind(function () use ($loader) {
            $loader->prefixLengthsPsr4 = ComposerStaticInitb84761f57e62a6a534584b91ca213591::$prefixLengthsPsr4;
            $loader->prefixDirsPsr4 = ComposerStaticInitb84761f57e62a6a534584b91ca213591::$prefixDirsPsr4;

        }, null, ClassLoader::class);
    }
}

静态初始化类的核心就是 getInitializer() 函数，它将自己类中的顶级命名空间映射给了 ClassLoader 类。

PSR4 标准顶级命名空间映射用了两个数组，第一个是用命名空间第一个字母作为前缀索引，然后是 顶级命名空间，但是最终并不是文件路径，而是 顶级命名空间的长度。为什么呢？

因为 PSR4 标准是用顶级命名空间目录替换顶级命名空间，所以获得顶级命名空间的长度很重要。

ClassLoader

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
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
public function register($prepend = false)
{
    spl_autoload_register(array($this, 'loadClass'), true, $prepend);
}

public function loadClass($class)
{
    if ($file = $this->findFile($class)) {
        includeFile($file);

        return true;
    }
}

/**
* Finds the path to the file where the class is defined.
*
* @param string $class The name of the class
*
* @return string|false The path if found, false otherwise
*/
public function findFile($class)
{
    // class map lookup
    if (isset($this->classMap[$class])) {
        return $this->classMap[$class];
    }
    if ($this->classMapAuthoritative || isset($this->missingClasses[$class])) {
        return false;
    }
    if (null !== $this->apcuPrefix) {
        $file = apcu_fetch($this->apcuPrefix.$class, $hit);
        if ($hit) {
            return $file;
        }
    }

    $file = $this->findFileWithExtension($class, '.php');

    // Search for Hack files if we are running on HHVM
    if (false === $file && defined('HHVM_VERSION')) {
        $file = $this->findFileWithExtension($class, '.hh');
    }

    if (null !== $this->apcuPrefix) {
        apcu_add($this->apcuPrefix.$class, $file);
    }

    if (false === $file) {
        // Remember that this class does not exist.
        $this->missingClasses[$class] = true;
    }

    return $file;
}

function includeFile($file)
{
    include $file;
}

ClassLoader 的 register() 函数将 loadClass() 函数注册到 PHP 的 SPL 函数堆栈中，每当 PHP 遇到不认识的命名空间时就会调用函数堆栈的每个函数，直到加载命名空间成功。所以 loadClass() 函数就是自动加载的关键了。

发表于 | 分类于

在PHP开发过程中，如果希望从外部引入一个class，通常会使用include和require方法，去把定义这个class的文件包含进来。这个在小规模开发的时候，没什么大问题。但在大型的开发项目中，这么做会产生大量的require或者include方法调用，这样不因降低效率，而且使得代码难以维护，况且require_once的代价很大。

在PHP5之前，各个PHP框架如果要实现类的自动加载，一般都是按照某种约定自己实现一个遍历目录，自动加载所有符合约定规则的文件的类或函数。在PHP5后，当加载PHP类时，如果类所在文件没有被包含进来，或者类名出错，Zend引擎会自动调用__autoload()函数。此函数需要用户自己实现__autoload()函数。 在PHP5.1.2版本后，可以使用spl_autoload_register()函数自定义自动加载处理函数。当没有调用此函数，默认情况下会使用SPL自定义的spl_autoload函数。

__autoload

__autoload() 是php中的一个魔术方法，在代码中当调用不存在的类时会自动调用该方法。

语法

1
_autoload ( string $class ) : void  // class: 待加载的类名

用法

1
2
3
4
5
6
7
8
<?php

function __autoload($className) 
{
	echo 'autoload自动加载', $className,'<br />';
}

$myClass1 = new MyClass1();

如果调用某个未经include/require的类，在报错之前，还可以__autoload()函数得到一次介入机会，系统会调用__autoload()函数，并把类名传给__autoload()函数，就可以在__autoload()里加载需要的类。

例如：

1
2
3
4
5
<?php

function __autoload($classname) {
        require_once ($classname . ".class.php");
}

因此，当有大量的类文件要包含的时候，我们只要确定相应的规则，然后在__autoload()函数中，将类名与实际的磁盘文件对应起来，就可以实现lazy loading的效果。

缺陷

但现在问题来了，假如在一个系统的实现中，假如需要使用很多其它的类库，这些类库可能是由不同的开发工程师开发，其类名与实际的磁盘文件的映射规则不尽相同。这时假如要实现类库文件的自动加载，就必须在__autoload()函数中将所有的映射规则全部实现，因此__autoload()函数有可能会非常复杂，甚至无法实现。最后可能会导致__autoload()函数十分臃肿，这时即便能够实现，也会给将来的维护和系统效率带来很大的负面影响。所有问题都出现在__autoload() 是全局函数只能定义一次 ，那么如何来解决这个问题呢？答案就是使用一个 __autoload调用堆栈 ，不同的映射关系写到不同的 __autoload函数 中去，然后统一注册统一管理，这个就是 PHP5 引入的 SPL Autoload。

spl_autoload_register

spl_autoload_register()是SPL(Standard PHP Library)提供的方法。

语法

1
spl_autoload_register ([ callable $autoload_function [, bool $throw = true [, bool $prepend = false ]]] ) : bool
  • autoload_function：注册的自动装载函数
  • throw：此参数设置了 autoload_function 无法成功注册时， spl_autoload_register()是否抛出异常
  • prepend：如果是 true，spl_autoload_register() 会添加函数到队列之首，而不是队列尾部

用法

一旦调用spl_autoload_register()函数，当调用未定义类时，系统会按顺序调用注册到spl_autoload_register()函数的所有函数，而不是自动调用__autoload()函数。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
<?php
error_reporting(E_ALL);
ini_set('display_errors', 1);

use Autoload\TestClass;

function __autoload($className) 
{
	echo 'autoload自动加载', $className,'<br />';
}

spl_autoload_register(function($className){
	echo 'spl autoload自动加载1', $className,'<br />';
});

spl_autoload_register(function($className){
	echo 'spl autoload自动加载2', $className,'<br />';
});

$myClass1 = new MyClass1();

结果输出：

1
2
3
4
spl autoload自动加载1MyClass1
spl autoload自动加载2MyClass1

Fatal error: Uncaught Error: Class 'MyClass1' not found in /www/websites/www/gitlib/php/autoload.php:20 Stack trace: #0 {main} thrown in /www/websites/www/gitlib/php/autoload.php on line 20

还可以调用spl_autoload_register()函数以注册一个回调函数,而不是为函数提供一个字符串名称。如提供一个如array(‘class’,’method’)这样的数组，使得可以使用某个对象的方法。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
// 静态方法
class MyClass 
{
	public static function autoload($className) 
	{
		echo 'class autoload自动加载', $className,'<br />';
	}
}

spl_autoload_register(array('MyClass', 'autoload'));

// 实例
$myClass = new MyClass();

spl_autoload_register(array('myClass', 'autoload'));

$myClass1 = new MyClass1();

这样，就可以通过spl_autoload_regsiter()这个函数注册多个我们自己的 autoload() 函数，当 PHP 找不到类名时，PHP就会调用这个堆栈，然后去调用自定义的 autoload() 函数，实现自动加载功能。

发表于 | 分类于

1. OpenID Connect简介

OpenID Connect(OIDC)是2014年初发布的开放标准，定义了一种基于OAuth2的可互操作的方式来来提供用户身份认证。它使用简单的REST/JSON消息流来实现，和之前任何一种身份认证协议相比，开发者可以轻松集成。OpenID Connect使用 API 进行身份交互的框架，允许客户端根据授权服务器的认证结果最终确认用户的身份，以及获取基本的用户信息；支持包括Web、移动、JavaScript在内的所有客户端类型；它是可扩展的协议，允许你使用某些可选功能，如身份数据加密、OpenID提供商发现、会话管理等。

1.1 OpenID Connect 角色介绍

  1. 客户端：直接为终端用户提供服务
  2. 认证服务：OpenID 提供方，通常是一个 OpenID 认证服务器，它能为第三方颁发用于认证的ID Token
  3. 业务服务：提供业务服务，比如查询用户资料
  4. 终端用户：指持有资源拥有人

1.2 OpenID Connect 流程描述

openid connect

  1. 客户端发送认证请求给认证服务；
  2. 终端用户在认证页面进行授权确认（可选）；
  3. 认证服务对认证请求进行验证，发送ID Token给客户端；
  4. 客户端向业务请求，请求中携带ID Token；
  5. 业务服务验证ID Token是否合法后返回业务应答；

这个流程的第二步是可选的，如果终端用户在客户端输入了用户名和密码，第一步中的认证请求中携带了用户名和密码，那么认证服务在验证了用户名和密码后，省去第二步，可以直接在应答中返ID Token。这种模式更加简洁。

1.3 JWT(JSON Web Token)格式数据

认证服务返回的ID Token需要严格遵守JWT(JSON Web Token)的定义，下面是JWT(JSON Web Token)的定义细节：

  1. iss：必须。Issuer Identifier，认证服务的唯一标识，一个区分大小写的https URL，不包含query和fragment组件
  2. sub：必须。Subject Identifier，iss提供的终端用户的标识，在iss范围内唯一，最长为255个ASCII个字符，区分大小写
  3. aud：必须。Audience(s)，标识ID Token的受众，必须包含OAuth2的client_id，分大小写的字符串数组
  4. exp：必须。Expiration time，超过此时间的ID Token会作废
  5. iat：必须。Issued At Time，JWT的构建的时间
  6. auth_time：AuthenticationTime，终端用户完成认证的时间。
  7. nonce：发送认证请求的时候提供的随机字符串，用来减缓重放攻击，也可以用来关联客户端Session。如果nonce存在，客户端必须验证nonce
  8. acr：可选。Authentication Context Class Reference，表示一个认证上下文引用值，可以用来标识认证上下文类
  9. amr：可选。Authentication Methods References，表示一组认证方法
  10. azp：可选。Authorized party，结合aud使用。只有在被认证的一方和受众（aud）不一致时才使用此值，一般情况下很少使用

下面是一个典型ID Token的示例，供参考：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
{
    "iss": "https://1.2.3.4:8443/auth/realms/kubernetes",
    "sub": "547cea22-fc8a-4315-bdf2-6c92592a6e7c",
    "aud": "kubernetes",
    "exp": 1525158711,
    "iat": 1525158411,
    "auth_time": 0,
    "nonce": "n-0S6_WzA2Mj",
    "acr": "1",
    "azp": "kubernetes",
    "nbf": 0,
    "typ": "ID",
    "session_state": "150df80e-92a1-4b0c-a5c5-8c858eb5a848",
    "userId": "123456",
    "preferred_username": "theone",
    "given_name": "the",
    "family_name": "one",
    "email": "theone@mycorp.com"
}

关于ID Token的更详细的定义请参考： https://openid.net/specs/openid-connect-core-1_0.html

2. API网关OpenID Connect业务流程

阿里云API网关将OpenID Connect作为用户自主授权API的一种认证模式。作为处于客户端和后端服务中间的API网关，可以为后端服务去验证ID Token的合法性，并将没有拿到后端服务颁发的合法ID Token的请求在API网关层面给拒绝了。

2.1 准备条件

用户需要在API网关上配置以下两点，才能正常使用API网关的OpenID Connect认证模式：

  1. 配置一个获取授权API，并且在这个API上指定一个公钥；
  2. 所有需要保护的业务API设置成为OpenID Connect的业务API；

2.2 业务流程

openid connect

上图是API网关处理OpenID Connect的的整个业务流程，下面我们用文字来详细描述下：

  1. 客户端向API网关发起认证请求，请求中一般会携带终端用户的用户名和密码；
  2. API网关将请求直接转发给后端服务；
  3. 后端服务读取请求中的验证信息（比如用户名、密码）进行验证，验证通过后使用私钥生成标准的ID Token，返回给API网关；
  4. API网关将携带ID Token的应答返回给客户端，客户端需要将这个ID Token缓存到本地；
  5. 客户端向API网关发送业务请求，请求中携带ID Token；
  6. API网关使用用户设定的公钥对请求中的ID Token进行验证，验证通过后，将请求透传给后端服务；
  7. 后端服务进行业务处理后应答；
  8. API网关将业务应答返回给客户端。

在这个整个过程中，API网关利用OpenID Connect的认证机制，实现了用户使用自己的用户体系对自己API进行授权的能力。

2.3 授权范围与时效

API网关会认为用户颁发的ID Token有权利访问整个分组下的所有OpenID Connect的业务API。如果需要更细力度的权限管理，还需要后端服务自己解开ID Token进行权限认证。API网关会验证ID Token中的exp字段，一旦这个字段过期了，API网关会认为这个ID Token无效而将请求直接打回。过期时间这个值必须设置，并且过期时间一定要小于7天。

发表于 | 分类于

JSON Web Token（JWT）是目前最流行的跨域身份验证解决方案, 定义了一种紧凑且自包含的，用于在多方传递JSON对象的技术。

在了解JWT之前，先了解一下目前两种主流身份验证方式：传统身份验证、基于Token的身份验证。

传统身份验证

HTTP 是一种无状态的协议，没有上下文会话机制，每一条HTTP请求都是相互独立的。为了识别用户和保存用户的状态，可以依靠Cookie和Session来处理，流程如下：

  1. 客户端使用用户名密码进行认证
  2. 服务端生成并存储 Session，将 SessionID 通过 Cookie 返回给客户端
  3. 客户端访问需要认证的接口时在 Cookie 中携带 SessionID
  4. 服务端通过 SessionID 查找 Session 并进行鉴权，返回给客户端需要的数据

jwt

这种身份验证方法，需要在服务端存储为登录的用户生成的Session，这些Session可能会存储在内存，磁盘，或者数据库里。

基于Token的身份验证

使用基于 Token 的身份验证方法，在服务端不需要存储用户的登录记录。大概的流程是这样的：

  1. 客户端使用用户名跟密码请求登录
  2. 服务端收到请求，去验证用户名与密码
  3. 验证成功后，服务端会签发一个 Token，再把这个 Token 发送给客户端
  4. 客户端收到 Token 以后可以把它存储起来，比如放在 Cookie 里或者 Local Storage 里
  5. 客户端每次向服务端请求资源的时候需要带着服务端签发的 Token
  6. 服务端收到请求，然后去验证客户端请求里面带着的 Token，如果验证成功，就向客户端返回请求的数据

jwt

JWT

JWT的原则是在服务器身份验证之后，将生成一个JSON对象并将其发送回用户。，当用户与服务器通信时，客户在请求中发回JSON对象。服务器仅依赖于这个JSON对象来标识用户。为了防止用户篡改数据，服务器将在生成对象时添加签名。 与基于Token的身份验证方法一样，服务器不保存任何会话数据，即服务器变为无状态，使其更容易扩展。

jwt

Jwt 形式的 token 一般分为 3 个部分，分别是 Header，Payload，Signature，这三个部分使用 .分隔(格式：Header.Payload.Signature) 。其中前两部分使用Base64URL编码，未经加密处理，第三个部分使用 RSA 加密。

jwt

头部(HEADER)

HEADER主要为了描述该JWT的最基本信息，主要包含两个部分：声明类型和声明加密算法(通常直接使用HMAC，SHA256)

1
2
3
4
{
  "alg": "HS256",
  "typ": "JWT"
}

载荷(PAYLOAD)

载荷主要是存放有效信息，这些信息按照职能可以分成三个部分:

  • 标准的注册声明
  • 公共的声明
  • 私有的声明
1
2
3
4
5
{
  "sub": "1234567890",
  "name": "John Doe",
  "admin": true
}

标准的注册声明：

  • iss：jwt签发者
  • sub：jwt所面向的用户
  • aud：接收jwt的一方
  • exp：jwt的过期时间，这个过期时间必须要大于签发时间
  • nbf：定义在什么时间之前，该jwt都是不可用的
  • iat：jwt的签发时间
  • jti：jwt的唯一身份标识，主要用来作为一次性token,从而回避重放攻击

公共的声明

公共的声明可以添加任何的信息。一般这里我们会存放一下用户的基本信息（非敏感信息）

私有的声明

私有声明是提供者和消费者所共同定义的声明，不要存放敏感信息。

这些声明分类和字段，只是建议不强制使用。

签证(SIGNATURE)

JWT的第三部分是一个签证信息，这个签证信息主要由三个部分组成：Header(BASE64后)，Payload(BASE64后)，secret。

1
2
3
4
HMACSHA256(
  base64UrlEncode(header) + "." +
  base64UrlEncode(payload),
  secret)

jwt

因为header和payload内容都是明文记录（base64编码，任何人获取到jwt之后都可以解码），除非记录的是加密数据，否则不排除泄露隐私数据的可能。不推荐在jwt中记录任何敏感数据。

jwt

JWT 默认是不加密，不加密的情况下，不要写入敏感数据 ，当然也可以在生成原始 Token 以后，用密钥再加密一次。

JWT使用方式

客户端接收服务器返回的JWT，将其存储在Cookie或localStorage中。此后，客户端将在与服务器交互中都会带JWT。如果将它存储在Cookie中，就可以自动发送，但是不会跨域，因此一般是将它放入HTTP请求的Header Authorization字段中。

1
Authorization: Bearer <token>

当跨域时，也可以将JWT被放置于POST请求的数据主体中。

发表于 | 分类于

在使用PHP框架(CI/TP)搭建项目时, 我们经常使用Nginx/Apache的URL Rewrite模块实现伪静态。例如, 访问URL: http://app.cn/page/13044, 同时我们也可以通过访：http://app.cn/index.php?/page/13044访问，打开的页面是一模一样的。在Nginx设置如下URL Rewrite规则就可以实现:

1
rewrite ^/(.*)$ /index.php?$1 last;

除了伪静态URL外，我们还可以通过其他几种URL模式访问。例如CI框架：

CI框架

CI框架中可选三种URL 模式，在application/config/config.php可以定义。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
/*
|--------------------------------------------------------------------------
| URI PROTOCOL
|--------------------------------------------------------------------------
|
| This item determines which server global should be used to retrieve the
| URI string.  The default setting of 'REQUEST_URI' works for most servers.
| If your links do not seem to work, try one of the other delicious flavors:
|
| 'REQUEST_URI'    Uses $_SERVER['REQUEST_URI']
| 'QUERY_STRING'   Uses $_SERVER['QUERY_STRING']
| 'PATH_INFO'      Uses $_SERVER['PATH_INFO']
|
| WARNING: If you set this to 'PATH_INFO', URIs will always be URL-decoded!
*/
$config['uri_protocol']	= 'REQUEST_URI';

REQUEST_URI

REQUEST_URI模式是CI框架默认URL模式，采用分析$_SERVER[‘REQUEST_URI’]来区分控制器/动作/参数。例如：http://localhost/index.php?/user/login?var=value

$_SERVER[‘REQUEST_URI’]值：index.php?/user/login?var=value

实现代码如下：

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
$uri = parse_url('http://dummy'.$_SERVER['REQUEST_URI']);
$query = isset($uri['query']) ? $uri['query'] : '';
$uri = isset($uri['path']) ? $uri['path'] : '';

if (isset($_SERVER['SCRIPT_NAME'][0]))
{
  if (strpos($uri, $_SERVER['SCRIPT_NAME']) === 0)
  {
    $uri = (string) substr($uri, strlen($_SERVER['SCRIPT_NAME']));
  }
  elseif (strpos($uri, dirname($_SERVER['SCRIPT_NAME'])) === 0)
  {
    $uri = (string) substr($uri, strlen(dirname($_SERVER['SCRIPT_NAME'])));
  }
}

// This section ensures that even on servers that require the URI to be in the query string (Nginx) a correct
// URI is found, and also fixes the QUERY_STRING server var and $_GET array.
if (trim($uri, '/') === '' && strncmp($query, '/', 1) === 0)
{
  $query = explode('?', $query, 2);
  $uri = $query[0];
  $_SERVER['QUERY_STRING'] = isset($query[1]) ? $query[1] : '';
}
else
{
  $_SERVER['QUERY_STRING'] = $query;
}

parse_str($_SERVER['QUERY_STRING'], $_GET);

在REQUEST_URI模式的基础上添加了重写规则的支持，可以去掉URL地址里面的入口文件index.php

1
2
3
4
5
6
<IfModule mod_rewrite.c> 
RewriteEngine on 
RewriteCond %{REQUEST_FILENAME} !-d 
RewriteCond %{REQUEST_FILENAME} !-f 
ewriteRule ^(.*)$ index.php/$1 [L]
</IfModule>

这样，就可以直接访问：http://localhost/user/login?var=value

QUERY_STRING

QUERT_STRING模式就是传统GET传参数来指定当前访问的模块和操作，例如： `http://localhost/?c=controller&m=method&var=value

c参数表示控制器，m参数表示控制器方法（这些参数都是可以配置的），后面的表示其他GET参数。

1
2
3
$config['enable_query_strings'] = FALSE;
$config['controller_trigger'] = 'c';
$config['function_trigger'] = 'm';

PATH_INFO

PATH-INFO：浏览器用GET方式发送数据时的附加路径

PATHINFO模式下的URL访问地址是： http://localhost/index.php/user/login/var/value/

Apache默认支持PATH_INFO, Nginx则需要改造一下：

1
2
3
4
5
6
7
8
location ~  ^(.+\.php)(.*)$ {
  fastcgi_pass  127.0.0.1:9000;
  fastcgi_index index.php;
  fastcgi_split_path_info       ^(.+\.php)(.*)$;
  fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
  fastcgi_param PATH_INFO       $fastcgi_path_info;
  include fastcgi_params;
}

PATHINFO安全漏洞：http://www.laruence.com/2010/05/20/1495.html (此漏洞已经修复，访问会出现Access denied)

TP

TP(3.2)框架中可以选择四种URL模式。

普通模式

普通模式也就是传统的GET传参方式来指定当前访问的模块和操作，例如： http://localhost/?m=home&c=user&a=login&var=value

m参数表示模块，c参数表示控制器，a参数表示操作（当然这些参数都是可以配置的），后面的表示其他GET参数

如果默认的变量设置和你的应用变量有冲突的话，你需要重新设置系统配置，例如改成下面的：

1
2
3
'VAR_MODULE'            =>  'module',     // 默认模块获取变量
'VAR_CONTROLLER'        =>  'controller',    // 默认控制器获取变量
'VAR_ACTION'            =>  'action',    // 默认操作获取变量

上面的访问地址则变成： http://localhost/?module=home&controller=user&action=login&var=value

PATHINFO模式

PATHINFO模式是TP3.2默认URL模式，PATHINFO模式下面的URL访问地址是： http://localhost/index.php/home/user/login/var/value/

PATHINFO地址的前三个参数分别表示模块/控制器/操作

REWRITE模式

REWRITE模式是在PATHINFO模式的基础上添加了重写规则的支持，可以去掉URL地址里面的入口文件index.php，但是需要额外配置WEB服务器的重写规则。

1
2
3
4
5
6
<IfModule mod_rewrite.c>
RewriteEngine on
RewriteCond %{REQUEST_FILENAME} !-d
RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule ^(.*)$ index.php/$1 [L]
</IfModule>

接下来，就可以用下面的URL地址访问了： http://localhost/home/user/login/var/value

兼容模式

兼容模式是用于不支持PATHINFO的特殊环境，URL地址是： http://localhost/?s=/home/user/login/var/value

兼容模式配合Web服务器重写规则的定义，可以达到和REWRITE模式一样的URL效果。

1
2
3
4
5
6
<IfModule mod_rewrite.c>
 RewriteEngine on
 RewriteCond %{REQUEST_FILENAME} !-d
 RewriteCond %{REQUEST_FILENAME} !-f
 RewriteRule ^(.*)$ index.php?s=/$1 [QSA,PT,L]
</IfModule>

就可以和REWRITE模式一样访问下面的URL地址访问了： http://localhost/home/user/login/var/value

参考文档

发表于 | 分类于

介绍

Kong是一个可扩展的开源API网关, 基于OpenResty(lua-nginx-module)开发, 底层使用Apache Cassandra或PostgreSQL数据库，运行在任何RESTful API的前面，并通过插件扩展，开发者可以方便的添加已定义的插件，甚至可以自己开发插件并使用，来达到代理、负载均衡、健康检查、日志、登录等功能。

kong

Kong主要有三个组件：

  • Kong Server ：基于nginx的服务器，用来接收API请求。
  • Cassandra/PostgreSQL ：用来存储数据。
  • Kong dashboard：官方推荐UI管理工具，当然，也可以使用 restfull 方式 管理admin api

安装部署

Kong官方提供了各平台/系统的安装文档，推荐用Docker来进行安装部署。

创建Docker网络

Kong Server依赖Cassandra/PostgreSQL数据库，便于容器之间通信，先创建一个docker网络。

1
docker network create kong-net

安装启动postgresSQL

1
2
3
4
5
6
docker run -d --name kong-database \
               --network=kong-net \
               -p 5432:5432 \
               -e "POSTGRES_USER=kong" \
               -e "POSTGRES_DB=kong" \
               postgres:9.6

导入数据

1
2
3
4
5
6
docker run --rm \
     --network=kong-net \
     -e "KONG_DATABASE=postgres" \
     -e "KONG_PG_HOST=kong-database" \
     -e "KONG_CASSANDRA_CONTACT_POINTS=kong-database" \
     kong:latest kong migrations bootstrap

安装启动Kong

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
docker run -d --name kong \
     --network=kong-net \
     -e "KONG_DATABASE=postgres" \
     -e "KONG_PG_HOST=kong-database" \
     -e "KONG_CASSANDRA_CONTACT_POINTS=kong-database" \
     -e "KONG_PROXY_ACCESS_LOG=/dev/stdout" \
     -e "KONG_ADMIN_ACCESS_LOG=/dev/stdout" \
     -e "KONG_PROXY_ERROR_LOG=/dev/stderr" \
     -e "KONG_ADMIN_ERROR_LOG=/dev/stderr" \
     -e "KONG_ADMIN_LISTEN=0.0.0.0:8001, 0.0.0.0:8444 ssl" \
     -p 8000:8000 \
     -p 8443:8443 \
     -p 8001:8001 \
     -p 8444:8444 \
     kong:latest

Kong默认监听下面端口：

  • 8000：监听来自客户端的HTTP流量，转发到你的upstream服务上
  • 8443：监听HTTPS的流量，功能跟8000一样。可以通过配置文件禁止
  • 8001：Kong的HTTP监听的api管理接口
  • 8444：Kong的HTTPS监听的API管理接口

安装Kong Admin-UI

Kong暴露了一个RESTful管理Api在8001端口上，Kong的配置，包括添加Service和Route,都是通过这个Api发送请求。市面上有很多基于RESTful管理API后台项目，官方的Kong dashboard在我本地安装之后，无法正常使用，推荐一个纯前端的管理后台：Kong-admin-ui

1
docker run -d --name kong-admin-ui -p 8899:80 pocketdigi/kong-admin-ui:0.4.0

kong

安装完成之后，运行docker ps看一下当前运行的容器：

1
2
3
4
CONTAINER ID        IMAGE                            COMMAND                  CREATED             STATUS              PORTS                                                                NAMES
47968f8067bd        pocketdigi/kong-admin-ui:0.3.2   "nginx -g 'daemon of…"   43 seconds ago      Up 43 seconds       0.0.0.0:8899->80/tcp                                                 kong-admin-ui
c8096b5374f5        kong:latest                      "/docker-entrypoint.…"   10 minutes ago      Up 10 minutes       0.0.0.0:8000-8001->8000-8001/tcp, 0.0.0.0:8443-8444->8443-8444/tcp   kong
bf526e28d65a        postgres:9.6                     "docker-entrypoint.s…"   30 minutes ago      Up 30 minutes       0.0.0.0:5432->5432/tcp

Kong配置

安装完成各项服务之后，我们就可以通过RESTful管理Api配置服务/路由/插件，因为可视化操作相对直观，这里推荐使用管理后台进行。

添加服务

RESTful接口

1
2
3
4
curl -i -X POST \
  --url http://localhost:8001/services/ \
  --data 'name=example-service' \
  --data 'url=http://mockbin.org'

返回数据格式：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
HTTP/1.1 201 Created
Content-Type: application/json
Connection: keep-alive

{
   "host":"mockbin.org",
   "created_at":1519130509,
   "connect_timeout":60000,
   "id":"92956672-f5ea-4e9a-b096-667bf55bc40c",
   "protocol":"http",
   "name":"example-service",
   "read_timeout":60000,
   "port":80,
   "path":null,
   "updated_at":1519130509,
   "retries":5,
   "write_timeout":60000
}
Permalink

也可以通过管理后台添加：

kong

kong

为服务添加路由

添加为服务（API）配置之后，还需要给服务添加路由，让网关知道在什么情况下将请求转发给服务。

RESTful接口：

1
2
3
curl -i -X POST \
  --url http://localhost:8001/services/example-service/routes \
  --data 'hosts[]=example.com'

返回数据：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
HTTP/1.1 201 Created
Content-Type: application/json
Connection: keep-alive

{
   "created_at":1519131139,
   "strip_path":true,
   "hosts":[
      "example.com"
   ],
   "preserve_host":false,
   "regex_priority":0,
   "updated_at":1519131139,
   "paths":null,
   "service":{
      "id":"79d7ee6e-9fc7-4b95-aa3b-61d2e17e7516"
   },
   "methods":null,
   "protocols":[
      "http",
      "https"
   ],
   "id":"f9ce2ed7-c06e-4e16-bd5d-3a82daef3f9d"
}

通过管理后台操作：

kong

通过Kong转发请求

配置完服务和路由之后，就可以通过Kong来转发请求了。

1
2
3
curl -i -X GET \
  --url http://localhost:8000/ \
  --header 'Host: example.com'

在上面请求中，因为配置了指定的host路由，Kong会转发请求到对应的服务。

添加插件

Kong 的插件机制是其高可扩展性的根源，Kong 可以很方便地为路由和服务提供各种插件，网关所需要的基本特性，Kong 都如数支持：

  • 云原生: 与平台无关，Kong可以从裸机运行到Kubernetes
  • 动态路由：Kong 的背后是 OpenResty+Lua，所以从 OpenResty 继承了动态路由的特性
  • 熔断
  • 健康检查
  • 日志: 可以记录通过 Kong 的 HTTP，TCP，UDP 请求和响应。
  • 鉴权: 权限控制，IP 黑白名单，同样是 OpenResty 的特性
  • SSL: Setup a Specific SSL Certificate for an underlying service or API.
  • 监控: Kong 提供了实时监控插件
  • 认证: 如数支持 HMAC, JWT, Basic, OAuth2.0 等常用协议
  • 限流
  • REST API: 通过 Rest API 进行配置管理，从繁琐的配置文件中解放
  • 可用性: 天然支持分布式
  • 高性能: 背靠非阻塞通信的 nginx，性能自不用说
  • 插件机制: 提供众多开箱即用的插件，且有易于扩展的自定义插件接口，用户可以使用 Lua 自行开发插件

关于Kong的插件可以看官方文档：https://docs.konghq.com/hub/

RESTful接口：

1
2
3
4
curl -X POST http://localhost:8001/services/example-service/plugins \
    --data "name=rate-limiting"  \
    --data "config.second=5" \
    --data "config.hour=10000"

这样，我们就为example-service添加了一个rate-limiting插件，该插件会依据config配置限制example-service的请求频率，当超限是就会报错：

1
2
3
{
    "message": "API rate limit exceeded"
}

同样，我们也可以在管理后台操作。

kong

添加Consumer

Consumer可以理解为用户（消费者），用来标记某个用户或者某个服务。例如某个Service开启了key-auth插件，那么访问这个Service需要传入key，这个时候我们可以定义一个Consumer，给它添加一个key，这个时候通过这个key（当然key是唯一的）访问Service时，网关就可以判断是哪个Consumer发送的请求。

创建Consumer

1
2
3
curl -i -X POST \
  --url http://localhost:8001/consumers/ \
  --data "username=Jason"

为Consumer添加证书

1
2
3
curl -i -X POST \
  --url http://localhost:8001/consumers/Jason/key-auth/ \
  --data 'key=ENTER_KEY_HERE'

验证Consumer凭证

执行下面的命令，验证Consumer凭证

1
2
3
4
curl -i -X GET \
  --url http://localhost:8000 \
  --header "Host: example.com" \
  --header "apikey: ENTER_KEY_HERE"

参考文档

发表于 | 分类于

在我们编写Dockerfile时，CMD 和 ENTRYPOINT 指令都可以用来指定容器启动时运行的命令，从程序设计角度来说，Docker不可能提供两种一样的指令，它们之间究竟有什么差异和关联呢？

在了解两者差异之前，我们先了解一下Dockerfile中两种启动命令编写模式：

  • exec模式：CMD ["a", "b", "c"]， 容器启动后会执行命令：a b c
  • Shell：CMD "a" , 容器启动后会执行命令：/bin/sh a

可以看出，exec模式采用数组的形式，容器启动时会把数组中的值依次转化组合成shell命令，而shell模式则是采用字符串的形式，字符串会作为/bin/sh -c的参数。

下面通过 CMD 指令来验证 exec 模式和 shell 模式。

exec 模式

1
2
FROM ubuntu
CMD ["top"]

将上面代码保存到Dockerfile中，然后构建镜像并启动一个容器。

1
2
3
4
# 构建镜像
docker build -t ubuntu/test:1 .
# 启动容器
docker run -itd --name ubuntu-test-1 ubuntu/test:1

检查一下容器是否在运行：docker ps -a

docker

可以看出容器在后台正常运行，查看一下容器的进程：

1
docker exec ubuntu-test-1 ps aux

docker

可以看到top命令正在运行，pid为1。

shell 模式

1
2
3
FROM ubuntu

CMD "top"

将上面代码保存到Dockerfile中，同样构建镜像并启动一个容器。

1
2
3
4
# 构建镜像
docker build -t ubuntu/test:2 .
# 启动容器
docker run -itd --name ubuntu-test-2 ubuntu/test:2

查看当前所有容器：docker ps -a

docker

可以看到当前容器运行的命令是：/bin/sh -c \"top\", 而之前容器运行的命令是："top"， 验证了exec模式和shell模式的差异。

查看一下当前容器的进程：

1
docker exec ubuntu-test-2 ps aux

docker

1号进程是/bin/sh -c "top"，top命令pid是6。

CMD与ENTRYPOINT差异

关于CMD与ENTRYPOINT有几条铁律：

  • 在Dockerfile中，只能有一个ENTRYPOINT指令，如果有多个ENTRYPOINT指令则以最后一个为准；
  • 在Dockerfile中，只能有一个CMD指令，如果有多个CMD指令则以最后一个为准；
  • 执行docker run如果带有其他命令参数，将会覆盖CMD指令；

同时Docker官方文档中，给出了CMD指令的用法:

  • CMD [“executable”,”param1”,”param2”] (exec form, this is the preferred form)
  • CMD [“param1”,”param2”] (as default parameters to ENTRYPOINT)
  • CMD command param1 param2 (shell form)

结合以上几点，我们可以知道，当同时存在CMD指令和ENTRYPOINT指令时，只会执行ENTRYPOINT指令，至于如何处理CMD指令，就要分很多种情况，可见官方说明：

docker

在日常开发中，ENTRYPOINT指令，往往用于设置容器启动后的第一个命令，CMD指令，往往用于设置容器启动的第一个命令的默认参数，这对一个容器来说可以是变化的。