来源： Decimal 保留2为小数。 – calm_水手 – 博客园

保留小数位的方法，有下面这几种:Math.Round();Decimal.Round();.ToString(“#0.00”);.ToString(“N2”)

其中.Round()方法是四舍六入(五五才进一)；.ToString(“#0.00”)和.ToString(“N2”)为四舍五入。

如Decimal  num=1.2355m;

.Rountd(num,2)=1.24; .ToString(“#0.00”)和.ToString(“N2”)= 1.24;

Decimal num=1.2354m;

.Rountd(num,2)=1.23; .ToString(“#0.00”)和.ToString(“N2”)= 1.24;

取整

.ToString(“#0”);

来源： Docker系列之入门篇 – 潇十一郎 – 博客园

$ sudo yum remove docker \
                  docker-client \
                  docker-client-latest \
                  docker-common \
                  docker-latest \
                  docker-latest-logrotate \
                  docker-logrotate \
                  docker-selinux \
                  docker-engine-selinux \
                  docker-engine

$ sudo yum install -y yum-utils \
  device-mapper-persistent-data \
  lvm2

$ sudo yum-config-manager \
    --add-repo \
    https://download.docker.com/linux/centos/docker-ce.repo

$ sudo yum-config-manager --enable docker-ce-edge

$ sudo yum-config-manager --enable docker-ce-test

//您可以通过运行带有标志的命令来禁用边缘或测试存储库 。要重新启用它，请使用该标志。以下命令禁用边缘存储库。yum-config-manager--disable--enable

$ sudo yum-config-manager --disable docker-ce-edge

//注意：从Docker 17.06开始，稳定版本也会被推送到边缘并测试存储库。

$ sudo yum install docker-ce

$ sudo systemctl start docker

$ sudo docker run hello-world

来源： Westore 1.0 正式发布 – 小程序框架一个就够 – 【当耐特】 – 博客园

Github： https://github.com/dntzhang/westore

众所周知，小程序通过页面或组件各自的 setData 再加上各种父子、祖孙、姐弟、嫂子与堂兄等等组件间的通讯会把程序搞成一团浆糊，如果再加上跨页面之间的组件通讯，会让程序非常难维护和调试。虽然市面上出现了许多技术栈编译转小程序的技术，但是我觉没有戳中小程序的痛点。小程序不管从组件化、开发、调试、发布、灰度、回滚、上报、统计、监控和最近的云能力都非常完善，小程序的工程化简直就是前端的典范。而开发者工具也在持续更新，可以想象的未来，组件布局的话未必需要写代码了。所以最大的痛点只剩下状态管理和跨页通讯。

受 Omi 框架 的启发，且专门为小程序开发的 JSON Diff 库，所以有了 westore 全局状态管理和跨页通讯框架让一切尽在掌握中，且受高性能 JSON Diff 库的利好，长列表滚动加载显示变得轻松可驾驭。总结下来有如下特性和优势:

• 和 Omi 同样简洁的 Store API
• 超小的代码尺寸(包括 json diff 共100多行)
• 尊重且顺从小程序的设计(其他转译库相当于反其道行)
• this.update 比原生 setData 的性能更优，更加智能

• API
• 使用指南
  • 定义全局 store
  • 创建页面
  • 绑定数据
  • 更新页面
  • 创建组件
  • 更新组件
  • setData 和 update 对比
  • 跨页面同步数据
  • 调试
  • 超大型小程序最佳实践
• 原理
  • JSON Diff
  • Update
• License

API

Westore API 只有三个, 大道至简:

• create(store, option) 创建页面
• create(option) 创建组件
• this.update() 更新页面或组件

使用指南

定义全局 store

export default {
  data: {
    motto: 'Hello World',
    userInfo: {},
    hasUserInfo: false,
    canIUse: wx.canIUse('button.open-type.getUserInfo'),
    logs: []
  },
  logMotto: function () {
    console.log(this.data.motto)
  }
}

你不需要在页面和组件上再声明 data 属性。如果申明了也没关系，会被 Object.assign 覆盖到 store.data 上。后续只需修改 this.store.data 便可。

创建页面

import store from '../../store'
import create from '../../utils/create'

const app = getApp()

create(store, {

  onLoad: function () {
    if (app.globalData.userInfo) {
      this.store.data.userInfo = app.globalData.userInfo
      this.store.data.hasUserInfo = true
      this.update()
    } else if (this.data.canIUse) {
      app.userInfoReadyCallback = res => {
        this.store.data.userInfo = res.userInfo
        this.store.data.hasUserInfo = true
        this.update()
      }
    } else {
      wx.getUserInfo({
        success: res => {
          app.globalData.userInfo = res.userInfo
          this.store.data.userInfo = res.userInfo
          this.store.data.hasUserInfo = true
          this.update()
        }
      })
    }
  }

})

创建 Page 只需传入两个参数，store 从根节点注入，所有子组件都能通过 this.store 访问。

绑定数据

<view class="container">
   
  <view class="userinfo">
    <button wx:if="{{!hasUserInfo && canIUse}}" open-type="getUserInfo" bindgetuserinfo="getUserInfo"> 获取头像昵称 </button>
    <block wx:else>
      <image bindtap="bindViewTap" class="userinfo-avatar" src="{{userInfo.avatarUrl}}" mode="cover"></image>
      <text class="userinfo-nickname">{{userInfo.nickName}}</text>
    </block>
  </view>
  <view class="usermotto">
    <text class="user-motto">{{motto}}</text>
  </view>

  <hello></hello>
</view>

和以前的写法没有差别，直接把 store.data 作为绑定数据源。

更新页面

this.store.data.any_prop_you_want_to_change = 'any_thing_you_want_change_to'
this.update()

创建组件

import create from '../../utils/create'

create({
  ready: function () {
   //you can use this.store here
  },

  methods: {
    //you can use this.store here
  }
})

和创建 Page 不一样的是，创建组件只需传入一个参数，不需要传入 store，因为已经从根节点注入了。

更新组件

this.store.data.any_prop_you_want_to_change = 'any_thing_you_want_change_to'
this.update()

setData 和 update 对比

拿官方模板示例的 log 页面作为例子:

this.setData({
  logs: (wx.getStorageSync('logs') || []).map(log => {
    return util.formatTime(new Date(log))
  })
})

使用 westore 后:

this.store.data.logs = (wx.getStorageSync('logs') || []).map(log => {
  return util.formatTime(new Date(log))
})
this.update()

看似一条语句变成了两条语句，但是 this.update 调用的 setData 是 diff 后的，所以传递的数据更少。

跨页面同步数据

使用 westore 你不用关系跨页数据同步，你只需要专注 this.store.data 便可，修改完在任意地方调用 update 便可：

this.update()

调试

console.log(getApp().globalData.store.data)

超大型小程序最佳实践(两种方案)

不排除小程序被做大得可能，接触的最大的小程序有 60+ 的页面，所以怎么管理？这里给出了两个最佳实践方案。

• 第一种方案，拆分 store 的 data 为不同模块，如:

export default {
  data: {
    commonA: 'a',
    commonB: 'b',
    pageA: {
      a: 1
      xx: 'xxx'
    },
    pageB: {
      b: 2,
      c: 3
    }
  },
  xxx: function () {
    console.log(this.data)
  }
}

• 第二种方案，拆分 store 的 data 到不同文件且合并到一个 store 暴露给 create 方法，如：

a.js

export default {
  data: {
    a: 1
    xx: 'xxx'
  },
  aMethod: function (num) {
    this.data.a += num
  }
}

b.js

export default {
  data: {
    b: 2,
    c: 3
  },
  bMethod: function () {
    
  }
}

store.js

import a from 'a.js'
import b from 'b.js'

export default {
  data: {
    commonNum: 1,
    commonB: 'b',
    pageA: a.data
    pageB: b.data
  },
  xxx: function () {
    //you can call the methods of a or b and can pass args to them
    console.log(a.aMethod(commonNum))
  },
  xx: function(){

  }
}

当然，也可以不用按照页面拆分文件或模块，也可以按照领域来拆分，这个很自由，视情况而定。

原理

 ---------------       -------------------        -----------------------
| this.update  |  →  |     json diff     |   →  | setData()-setData()...|  →  之后就是黑盒(小程序官方实现，但是 dom/apply diff 肯定是少不了)
 ---------------       -------------------        -----------------------

虽然和 Omi 一样同为 store.updata 但是却有着本质的区别。Omi 的如下:

 ---------------       -------------------        ----------------         ------------------------------
|  this.update  |  →  |     setState      |   →  |  jsx rerender  |   →   |   vdom diff → apply diff...  |
 ---------------       -------------------        ----------------         ------------------------------

都是数据驱动视图，但本质不同，原因:

• 小程序 store 和 dom 不在同一个环境，先在 js 环境进行 json diff，然后使用 diff 结果通过 setData 通讯
• web 里使用 omi 的话 store 和 dom 在同一环境，setState 直接驱动的 vdom diff 然后把 diff 结果作用在真是 dom 上

JSON Diff

先看一下我为 westore 专门定制开发的 JSON Diff 库 的能力:

diff({
    a: 1, b: 2, c: "str", d: { e: [2, { a: 4 }, 5] }, f: true, h: [1], g: { a: [1, 2], j: 111 }
}, {
    a: [], b: "aa", c: 3, d: { e: [3, { a: 3 }] }, f: false, h: [1, 2], g: { a: [1, 1, 1], i: "delete" }, k: 'del'
})

Diff 的结果是:

{ "a": 1, "b": 2, "c": "str", "d.e[0]": 2, "d.e[1].a": 4, "d.e[2]": 5, "f": true, "h": [1], "g.a": [1, 2], "g.j": 111, "g.i": null, "k": null }

Diff 原理:

• 同步所有 key 到当前 store.data
• 携带 path 和 result 递归遍历对比所有 key value

export default function diff(current, pre) {
    const result = {}
    syncKeys(current, pre)
    _diff(current, pre, '', result)
    return result
}

同步上一轮 state.data 的 key 主要是为了检测 array 中删除的元素或者 obj 中删除的 key。

小程序 setData

setData 是小程序开发中使用最频繁的接口，也是最容易引发性能问题的接口。在介绍常见的错误用法前，先简单介绍一下 setData 背后的工作原理。setData 函数用于将数据从逻辑层发送到视图层（异步），同时改变对应的 this.data 的值（同步）。

其中 key 可以以数据路径的形式给出，支持改变数组中的某一项或对象的某个属性，如 array[2].message，a.b.c.d，并且不需要在 this.data 中预先定义。比如：

this.setData({
      'array[0].text':'changed data'
})

所以 diff 的结果可以直接传递给 setData，也就是 this.update。

setData 工作原理

小程序的视图层目前使用 WebView 作为渲染载体，而逻辑层是由独立的 JavaScriptCore 作为运行环境。在架构上，WebView 和 JavaScriptCore 都是独立的模块，并不具备数据直接共享的通道。当前，视图层和逻辑层的数据传输，实际上通过两边提供的 evaluateJavaScript 所实现。即用户传输的数据，需要将其转换为字符串形式传递，同时把转换后的数据内容拼接成一份 JS 脚本，再通过执行 JS 脚本的形式传递到两边独立环境。

而 evaluateJavascript 的执行会受很多方面的影响，数据到达视图层并不是实时的。

常见的 setData 操作错误:

• 频繁的去 setData
• 每次 setData 都传递大量新数据
• 后台态页面进行 setData

上面是官方截取的内容。使用 webstore 的 this.update 本质是先 diff，再执行一连串的 setData，所以可以保证传递的数据每次维持在最小。既然可以使得传递数据最小，所以第一点和第三点虽有违反但可以商榷。

Update

这里区分在页面中的 update 和 组件中的 update。页面中的 update 在 onLoad 事件中进行实例收集。

const onLoad = option.onLoad
option.onLoad = function () {
    this.store = store
    rewriteUpdate(this)
    store.instances[this.route] = []
    store.instances[this.route].push(this)
    onLoad && onLoad.call(this)
}
Page(option)

组件中的 update 在 ready 事件中进行行实例收集:

const ready = store.ready
store.ready = function () {
    this.page = getCurrentPages()[getCurrentPages().length - 1]
    this.store = this.page.store;
    this.setData.call(this, this.store.data)
    rewriteUpdate(this)
    this.store.instances[this.page.route].push(this)
    ready && ready.call(this)
}
Component(store)

rewriteUpdate 的实现如下:

function rewriteUpdate(ctx){
    ctx.update = () => {
        const diffResult = diff(ctx.store.data, originData)  
        for(let key in ctx.store.instances){
            ctx.store.instances[key].forEach(ins => {
                ins.setData.call(ins, diffResult)
            })
        }
        for (let key in diffResult) {
            updateOriginData(originData, key, diffResult[key])
        }
    }
}

License

MIT @dntzhang

Xcode 9.0和iOS11上架的坑Missing Info.plist value CFBundleIconName_Xydawn_新浪博客,Xydawn,

来源： Xcode 9.0和iOS11上架的坑Missing Info.plist value CFBundleIconName_Xydawn_新浪博客

Dear developer,

We have discovered one or more issues with your recent delivery for “XXXXX”. To process your delivery, the following issues must be corrected:

Missing Info.plist value – A value for the Info.plist key ‘CFBundleIconName’ is missing in the bundle ”XXXXXXX”. Apps built with iOS 11 or later SDK must supply app icons in an asset catalog and must also provide a value for this Info.plist key. For more information see http://help.apple.com/xcode/mac/current/#/dev10510b1f7.

Once these issues have been corrected, you can then redeliver the corrected binary.

Regards,

The App Store team

问题上面这样

解决方法很简单

如下图所示

不过 正常的iOS开发 基本上都是这样设置图标的

coco2dx 的项目不是

上架的话 需要改下

点击这个选项

如果你图标都设置好了

他会帮填充好的

来源： 关于’CFBundleIconName’ is missing问题的解决办法 – CSDN博客

博主一直在用cocos creator进行游戏开发，最近xcode升级到了最新的9.2版本，打算对最新的游戏进行提审，从打包到上传包的过程中，都没有问题，但是，当上传成功后，不一会儿就收到了苹果的错误提示邮件，邮件内容如下：

Dear developer,

We have discovered one or more issues with your recent delivery for “你的应用的名字”. To process your delivery, the following issues must be corrected:

Missing Info.plist value – A value for the Info.plist key ‘CFBundleIconName’ is missing in the bundle ‘你的应用的bundle ID’. Apps built with iOS 11 or later SDK must supply app icons in an asset catalog and must also provide a value for this Info.plist key. For more information see http://help.apple.com/xcode/mac/current/#/dev10510b1f7.

Once these issues have been corrected, you can then redeliver the corrected binary.

Regards,

The App Store team

仔细阅读上面的信息，你会发现，问题出在一个叫做CFBundleIconName的字段，就是说，需要在Info.plist文件中，添加一个该字段，添加完成后，默认显示的名字是Icon Name，该字段是一个String的字段，value值为空。如下图所示：

我这里设置了一个value值为AppIcon，这个后面慢慢会说到。
下面说这个AppIcon的问题，注意，是i的大写，不是L的小写。这个表示的是应用的图标。从苹果发回来的邮件可以看得出来，大概是从iOS11以后，应用的图标就要配置在这个AppIcon里面，而这个是什么呢？做iOS开发的可能更加了解一些，就是Assets.xcassets下面的那个AppIcon，如图所示：

但是对于一个cocos导出的项目，是没有这个东西的，所以，这里重新常见一个iOS的demo项目，如图所示：

然后，右键点击Assets.xcassets，show in finder，在文件夹中打开，然后，复制到自己的项目目录下，

完成后，将该目录拖到项目中去，类似如下效果：

然后，点击Assets.xcassets，在点击AppIcon，也就是之前上面的那个AppIcon的效果，剩下的，就是设置资源了。这里提供一个连接如下：

https://www.appicon.build/

进入这个链接，然后上传一张1024×1024的图片，会生成AppIcon所需要的图片，然后输入邮箱，图片资源会以压缩包的形式发送到你的邮箱里，然后下载下来，将整个AppIcon.appiconset目录，复制到项目里面即可，如图所示：

然后点击Assets.xcassets，再点击AppIcon，将图片依次拖拽到右边对应的位置即可。然后，配置项目的Build Settings下面的Asset Catalog App Icon Set Name，将这里填写成AppIcon，然后修改info.plist文件的Icon name，将里面天上AppIcon即可。

这时，就可以打包了。打包过程是没问题的，但是上传包的时候，会报错，报错信息如下：

这个时候千万不要慌，仔细阅读提示信息。读一下会发现，问题出在版本兼容问题上，当iOS版本小于7.0的时候，iphone/ipod需要的Icon尺寸为57×57，ipad需要的尺寸是72×72，也就是说，我们之前配置的AppIcon中，缺少这两个尺寸，那么怎么添加这两个尺寸呢？还是右键点击Assets.xcassets，然后在finder中打开，如图所示：

然后打开Assets.xcassets/AppIcon.appiconset/里面的Content.json文件，然后，添加如下内容：

    {
      "size" : "57x57",
      "idiom" : "iphone",
      "filename" : "Icon-57.png",
      "scale" : "1x"
    },
    {
      "size" : "72x72",
      "idiom" : "ipad",
      "filename" : "Icon-72.png",
      "scale" : "1x"
    },

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

那个fileName是你的对应的图片的名字，如果这里写错了，也没关系，写好后，保存，打开xcode，点击AppIcon，这里会多出几个Icon的尺寸，这就需要重新配置几张图片了，然后，将新切好的图片，和之前的图片放在一起，将AppIcon缺少的部分拖拽一下就好了。刚刚虽然是添加了2项，但是，系统会默认多添加好几个，所以，这部分是不需要担心的。

下面进行一些其他的说明：
1.关于那个Assets.xcassets。刚开始的时候。楼主不是很了解这个东西，所以就从一个iOS项目中直接复制进来了，其实这个东西是可以直接创建的。创建过程如下：

然后,点击创建：
创建成功后，然后，创建AppIcon：

我是用的之前的那种方式copy过来的，这种方式有个问题，就是不同的设备，会有自己单独的AppIcon的配置，iPhone，Apple Watch ，iPad是分开的，除非直接改那个Content.json文件。

其次，对该博客的参考资料进行一下相应的说明，该博客最开始参考的博客内容是cocos论坛中的一篇帖子，
Xcode9打包上传失败？CFBundleIconName is missing？

该博客引用了Stack Overflow中的一篇帖子进行讲解，链接如下：

Missing CFBundleIconName in Xcode9 iOS11 app release

其中，也包括那个生成iOS的AppIcon的方法的链接，都是引用Stack Overflow的内容。然后，博主在打包上传包的时候，由于最低兼容版本是iOS6.0，所以报错了，提示57×57和72×72的那几个问题，该问题参考了如下内容：

Application Loader提交ipa文件出现ERROR ITMS-90022问题解决方案

尊重各位博主的成果，这里将参考内容全部贴出来，供大家参考。

来源： C#中 decimal 的四舍五入 – TooKoo – 博客园

当：decimal sum = 123456.784M;

sum = decimal.Round(sum, 2 , MidpointRounding.AwayFromZero);

sum 的值为：123456.78

当：decimal sum = 123456.785M;

sum = decimal.Round(sum, 2 , MidpointRounding.AwayFromZero);

sum 的值为：123456.79

来源： IIS+Asp.Net Mvc必须知道的事（解决启动/重启/自动回收站点后第一次访问慢问题） – 东汉 – 博客园

问题现象：

ASP.NET Mvc站点部署在IIS上后，第一个用户第一次访问站点，都会比较慢，确切的说是访问站点的Action页面（即非静态页面，因为静态页面直接由IIS处理返回给用户即完成请求，而Action页面IIS要转交给Aspnet_Wp工作进程，进而涉及相关初始化操作，这些初始化操作是比较慢的。第二次访问站点就不需要再初始化了所以就快了）。

这种第一次访问慢的问题不仅发生在网站第一次部署启动，也发生在站点重启和站点程序池回收（经测试，第一次部署启动初始化所用时间会多一些，然后是站点重启，然后是站点回收）。

1.站点重启包含手动重启和修改web.config配置、修改IIS上站点配置、更新站点bin目录的dll等引起的自动重启。如果你的站点是新上线的web或者会持续修改添加功能的web，那难免会更新dll导致重启。其它编译型语言(比如java)也是如此，更新了服务端组件，都难免要重启站点。这边会分享.net环境下如何优化此问题；

2.站点程序池回收是IIS建议的，本来默认是29小时回收一次。为什么要建议回收呢，大致可以这样理解：一个每日定时回收的机制就像是在发生轻微内存泄露或者其它拖累Worker进程的因素的情况下，刷新IIS的良药，站点回收即节省了资源又提高了稳定性。然而，自动回收后第一次访问慢的问题困扰了许多人，其实只要稍微设置就可以解决，即没有困扰也拥有了回收的优点。

问题解决：

1.先在IIS上设置相应应用程序池的“高级设置”（IIS版本要在8或8以上，要知道IIS10早已出来了，如果你在用IIS很低的版本，然后在报怨IIS，我…），如下图，这样设置后，回收只会发生在凌晨04:00:00

要确定有安装IIS应用程序初始化功能，如下图

2.在IIS上设置站点的“高级设置”，把【预加载已启用】设置为true。

设置完这两步，当站点(自动)回收时，访问站点也是秒开不受任何影响，它的原理是在回收时会保持站点持续运行，这样的回收可以理解为把旧的Worker内容平滑的移到新的Worker上，然后回收掉旧的Worker。但是要注意，回收会导致站点内存信息丢失，因此如果你的设计是把session放在内存，则就要设置永不自动回收，那只要在第1步的基础上把【特定时间】清空即可。不过我个人会建议你不要设计session放内存，你更新个dll导致站点重启，内存也是清空的，你不如把session放在memcache/redis中，如果你的系统还没用上这些，那你就用cookie代替session吧，cookie更灵活适用的场景也更多。

现在回收的问题完美解决了，接下来说说站点重启。站点重启肯定是要重新加载配置重新加载dll（不想重新加载dll的，看文章最后一段），初始化是免不了，默认重启后第一个用户第一次访问站点会触发初始化，那么我们可以在站点启动/重启时，系统自动发一个站点请求，让系统自己尝尝第一次访问慢的问题。

IIS站点启动时机自动请求站点

1.启动站点时触发的时机

创建一个类，继承自IProcessHostPreloadClient接口，其Preload方法就是启动站点时触发。然后在里面自动访问站点，如下代码：

   public class ApplicationPreload : System.Web.Hosting.IProcessHostPreloadClient
    {
        public void Preload(string[] parameters)
        {         
            try
            {
                //自动请求的url，其中http://localhost:8001 最好配置在config中，这边只是演示。
                string url = "http://localhost:8001/home2/about";
                using (var webClient = new WebClient())
                {
                    webClient.DownloadStringAsync(new Uri(url));//要异步请求
                }
            }
            catch (Exception e)
            {
                MvcApplication.DoLogToTxt("Preload Error:" + e.Message);
            }
        }
    }

2. 修改IIS配置文件，让IIS能识别到刚写的ApplicationPreload类

打开IIS配置文件：%WINDIR%\System32\inetsrv\config\applicationHost.config

<applicationPools>
    <add name="MyAppWorkerProcess" managedRuntimeVersion="v4.0" startMode="AlwaysRunning" /> <!-- 上面我们在IIS程序池界面中有设置过startMode项为AlwaysRunning-->
</applicationPools>

<!-- ... -->

<sites>
    <site name="MySite" id="1">
        <application path="/" serviceAutoStartEnabled="true" serviceAutoStartProvider="ApplicationPreload" />
    </site>
</sites>

<serviceAutoStartProviders>
    <add name="ApplicationPreload" type="WebApplication1.ApplicationPreload, WebApplication1" />
</serviceAutoStartProviders>

最后一个条目的type，其中WebApplication1.ApplicationPreload是应用程序中实现IProcessHostPreloadClient接口的类的全名，WebApplication1是程序集名称。

设置完这两步也就搞定了启动站点时自动访问站点。

探讨

在上面设置之前，我测试只更新站点部分dll，第一次访问需要1~4秒，测试的站点是含有CMS源码的站点，不算小了。之前有个面试官说他们公司站点更新一个dll，第一次访问需要10~30秒，甚至更久，这样正在访问站点的用户就要等待，然后一直在报怨IIS和.Net，想要投奔java的怀抱（这里不比较两种语言，它们各自有自己的优势），我问他是不是在Global.asax里Application_Start做了太多自己的初始化，要么有些初始化在用户访问到时处理负担分担出去，要么Application_Start异步处理初始化动作，但是他说这些自己的初始化都是用户访问前必须初始化好的。这…应该是自己系统设计不够好不能怪.Net吧，如果是用了七七八八的第三方组件，比如EF初始化慢，那就换成轻量级的Dapper呗，然后好好学习一下《N种提升ASP.NET Mvc性能的方法》，不要闭门造车。

（你们更新一个站点的dll，第一次访问需要多少秒呢？）

那么，在上面设置之后 ，如果更新站点dll后第一次访问需要1~4秒的情况下，系统自动帮你做了第一次访问，很可能正在访问的用户就不怎么察觉得出来站点有重启过。如果是高并发访问的大型网站，那就应该有负载均衡（IIS可以用NLB做负载均衡，或考虑CDN或DNS解析时就做负载均衡），应该有分布式等。

最后 ，如果你的站点是因为更新dll而导致站点重启，而且对此问题深恶痛绝，那么可以用.net的动态加载dll来解决，不是用AppDomain动态加载和卸载dll（这个太麻烦），而是用Assembly.LoadFile加载dll。比如Controller所在的dll是MvcA.dll，它引用了LibA.dll，当这两个dll都有修改时，如何让站点加载到这两个最新版本的dll。这个可以解决的，如果实际应用中需要此需求的人多（请回复评论），我会再整理分享出来。

来源： Spring MVC 原理探秘 – 一个请求的旅行过程 – coolblog.xyz – 博客园

1.简介

在前面的文章中，我较为详细的分析了 Spring IOC 和 AOP 部分的源码，并写成了文章。为了让我的 Spring 源码分析系列文章更为丰富一些，所以从本篇文章开始，我将来向大家介绍一下 Spring MVC 的一些原理。在本篇文章中，你将会了解到 Spring MVC 处理请求的过程。同时，你也会了解到 Servlet 相关的知识。以及 Spring MVC 的核心 DispatcherServlet 类的源码分析。在掌握以上内容后，相信大家会对 Spring MVC 的原理有更深的认识。

如果大家对上面介绍的知识点感兴趣的话，那下面不妨和我一起来去探索 Spring MVC 的原理。Let`s Go。

2.一个请求的旅行过程

在探索更深层次的原理之前，我们先来了解一下 Spring MVC 是怎么处理请求的。弄懂了这个流程后，才能更好的理解具体的源码。这里我把 Spring MVC 处理请求的流程图画了出来，一起看一下吧：

如上，每一个重要的步骤上面都有编号。我先来简单分析一下上面的流程，然后再向大家介绍图中出现的一些组件。我们从第一步开始，首先，用户的浏览器发出了一个请求，这个请求经过互联网到达了我们的服务器。Servlet 容器首先接待了这个请求，并将该请求委托给 DispatcherServlet 进行处理。接着 DispatcherServlet 将该请求传给了处理器映射组件 HandlerMapping，并获取到适合该请求的拦截器和处理器。在获取到处理器后，DispatcherServlet 还不能直接调用处理器的逻辑，需要进行对处理器进行适配。处理器适配成功后，DispatcherServlet 通过处理器适配器 HandlerAdapter 调用处理器的逻辑，并获取返回值 ModelAndView。之后，DispatcherServlet 需要根据 ModelAndView 解析视图。解析视图的工作由 ViewResolver 完成，若能解析成功，ViewResolver 会返回相应的视图对象 View。在获取到具体的 View 对象后，最后一步要做的事情就是由 View 渲染视图，并将渲染结果返回给用户。

以上就是 Spring MVC 处理请求的全过程，上面的流程进行了一定的简化，比如拦截器的执行时机就没说。不过这并不影响大家对主过程的理解。下来来简单介绍一下图中出现的一些组件：

从上面的流程中可以看出，Spring MVC 对各个组件的职责划分的比较清晰。DispatcherServlet 负责协调，其他组件则各自做分内之事，互不干扰。经过这样的职责划分，代码会便于维护。同时对于源码阅读者来说，也会很友好。可以降低理解源码的难度，使大家能够快速理清主逻辑。这一点值得我们学习。

3.知其然，更要知其所以然

3.1 追根溯源之 Servlet

本章要向大家介绍一下 Servlet，为什么要介绍 Servlet 呢？原因不难理解，Spring MVC 是基于 Servlet 实现的。所以要分析 Spring MVC，首先应追根溯源，弄懂 Servlet。Servlet 是 J2EE 规范之一，在遵守该规范的前提下，我们可将 Web 应用部署在 Servlet 容器下。这样做的好处是什么呢？我觉得可使开发者聚焦业务逻辑，而不用去关心 HTTP 协议方面的事情。比如，普通的 HTTP 请求就是一段有格式的文本，服务器需要去解析这段文本才能知道用户请求的内容是什么。比如我对个人网站的 80 端口抓包，然后获取到的 HTTP 请求头如下：

如果我们为了写一个 Web 应用，还要去解析 HTTP 协议相关的内容，那会增加很多工作量。有兴趣的朋友可以考虑使用 Java socket 编写实现一个 HTTP 服务器，体验一下解析部分 HTTP 协议的过程。也可以参考我之前写的文章 – 基于 Java NIO 实现简单的 HTTP 服务器。

如果我们写的 Web 应用不大，不夸张的说，项目中对 HTTP 提供支持的代码会比业务代码还要多，这岂不是得不偿失。当然，在现实中，有现成的框架可用，并不需要自己造轮子。如果我们基于 Servlet 规范实现 Web 应用的话，HTTP 协议的处理过程就不需要我们参与了。这些工作交给 Servlet 容器就行了，我们只需要关心业务逻辑怎么实现即可。

下面，我们先来看看 Servlet 接口及其实现类结构，然后再进行更进一步的说明。

如上图，我们接下来按照从上到下顺序进行分析。先来看看最顶层的两个接口是怎么定义的。

3.1.1 Servlet 与 ServletConfig

先来看看 Servlet 接口的定义，如下：

public interface Servlet {

    public void init(ServletConfig config) throws ServletException;

    public ServletConfig getServletConfig();
    
    public void service(ServletRequest req, ServletResponse res) throws ServletException, IOException;
   
    public String getServletInfo();
    
    public void destroy();
}

init 方法会在容器启动时由容器调用，也可能会在 Servlet 第一次被使用时调用，调用时机取决 load-on-start 的配置。容器调用 init 方法时，会向其传入一个 ServletConfig 参数。ServletConfig 是什么呢？顾名思义，ServletConfig 是一个和 Servlet 配置相关的接口。举个例子说明一下，我们在配置 Spring MVC 的 DispatcherServlet 时，会通过 ServletConfig 将配置文件的位置告知 DispatcherServlet。比如：

<servlet>
    <servlet-name>dispatcher</servlet-name>
    <servlet-class>org.springframework.web.servlet.DispatcherServlet</servlet-class>
    <init-param>
        <param-name>contextConfigLocation</param-name>
        <param-value>classpath:application-web.xml</param-value>
    </init-param>
</servlet>

如上， 标签内的配置信息最终会被放入 ServletConfig 实现类对象中。DispatcherServlet 通过 ServletConfig 接口中的方法，就能获取到 contextConfigLocation 对应的值。

Servlet 中的 service 方法用于处理请求。当然，一般情况下我们不会直接实现 Servlet 接口，通常是通过继承 HttpServlet 抽象类编写业务逻辑的。Servlet 中接口不多，也不难理解，这里就不多说了。下面我们来看看 ServletConfig 接口定义，如下：

public interface ServletConfig {
    
    public String getServletName();

    public ServletContext getServletContext();

    public String getInitParameter(String name);

    public Enumeration<String> getInitParameterNames();
}

先来看看 getServletName 方法，该方法用于获取 servlet 名称，也就是 标签中配置的内容。getServletContext 方法用于获取 Servlet 上下文。如果说一个 ServletConfig 对应一个 Servlet，那么一个 ServletContext 则是对应所有的 Servlet。ServletContext 代表当前的 Web 应用，可用于记录一些全局变量，当然它的功能不局限于记录变量。我们可通过 标签向 ServletContext 中配置信息，比如在配置 Spring 监听器（ContextLoaderListener）时，就可以通过该标签配置 contextConfigLocation。如下：

<context-param>
    <param-name>contextConfigLocation</param-name>
    <param-value>classpath:application.xml</param-value>
</context-param>

关于 ServletContext 就先说这么多了，继续介绍 ServletConfig 中的其他方法。getInitParameter 方法用于获取 标签中配置的参数值，getInitParameterNames 则是获取所有配置的名称集合，这两个方法用途都不难理解。

以上是 Servlet 与 ServletConfig 两个接口的说明，比较简单。说完这两个接口，我们继续往下看，接下来是 GenericServlet。

3.1.2 GenericServlet

GenericServlet 实现了 Servlet 和 ServletConfig 两个接口，为这两个接口中的部分方法提供了简单的实现。比如该类实现了 Servlet 接口中的 void init(ServletConfig) 方法，并在方法体内调用了内部提供了一个无参的 init 方法，子类可覆盖该无参 init 方法。除此之外，GenericServlet 还实现了 ServletConfig 接口中的 getInitParameter 方法，用户可直接调用该方法获取到配置信息。而不用先获取 ServletConfig，然后再调用 ServletConfig 的 getInitParameter 方法获取。下面我们来看看 GenericServlet 部分方法的源码：

public abstract class GenericServlet 
    implements Servlet, ServletConfig, java.io.Serializable {

    // 省略部分代码

    private transient ServletConfig config;
    
    public GenericServlet() { } 
    
    /** 有参 init 方法 */
    public void init(ServletConfig config) throws ServletException {
        this.config = config;
        // 调用内部定义的无参 init 方法
        this.init();
    }

    /** 无参 init 方法，子类可覆盖该方法 */
    public void init() throws ServletException { }

    /** 未给 service 方法提供具体的实现 */
    public abstract void service(ServletRequest req, ServletResponse res) throws ServletException, IOException;

    public void destroy() { }

    /** 通过 getInitParameter 可直接从 ServletConfig 实现类中获取配置信息 */
    public String getInitParameter(String name) {
        ServletConfig sc = getServletConfig();
        if (sc == null) {
            throw new IllegalStateException(
                lStrings.getString("err.servlet_config_not_initialized"));
        }

        return sc.getInitParameter(name);
    } 

    public ServletConfig getServletConfig() {
        return config;
    }
    
    // 省略部分代码
}

如上，GenericServlet 代码比较简单，配合着我写注释，很容易看懂。

GenericServlet 是一个协议无关的 servlet，是一个比较原始的实现，通常我们不会直接继承该类。一般情况下，我们都是继承 GenericServlet 的子类 HttpServlet，该类是一个和 HTTP 协议相关的 Servlet。那下面我们来看一下这个类。

3.1.3 HttpServlet

HttpServlet，从名字上就可看出，这个类是和 HTTP 协议相关。该类的关注点在于怎么处理 HTTP 请求，比如其定义了 doGet 方法处理 GET 类型的请求，定义了 doPost 方法处理 POST 类型的请求等。我们若需要基于 Servlet 写 Web 应用，应继承该类，并覆盖指定的方法。doGet 和 doPost 等方法并不是处理的入口方法，所以这些方法需要由其他方法调用才行。其他方法是哪个方法呢？当然是 service 方法了。下面我们看一下这个方法的实现。如下：

@Override
public void service(ServletRequest req, ServletResponse res)
    throws ServletException, IOException {
    HttpServletRequest  request;
    HttpServletResponse response;
    
    if (!(req instanceof HttpServletRequest &&
            res instanceof HttpServletResponse)) {
        throw new ServletException("non-HTTP request or response");
    }

    request = (HttpServletRequest) req;
    response = (HttpServletResponse) res;

    // 调用重载方法，该重载方法接受 HttpServletRequest 和 HttpServletResponse 类型的参数
    service(request, response);
}

protected void service(HttpServletRequest req, HttpServletResponse resp)
    throws ServletException, IOException {
    String method = req.getMethod();

    // 处理 GET 请求
    if (method.equals(METHOD_GET)) {
        long lastModified = getLastModified(req);
        if (lastModified == -1) {
            // 调用 doGet 方法
            doGet(req, resp);
        } else {
            long ifModifiedSince = req.getDateHeader(HEADER_IFMODSINCE);
            if (ifModifiedSince < lastModified) {
                maybeSetLastModified(resp, lastModified);
                doGet(req, resp);
            } else {
                resp.setStatus(HttpServletResponse.SC_NOT_MODIFIED);
            }
        }

    // 处理 HEAD 请求
    } else if (method.equals(METHOD_HEAD)) {
        long lastModified = getLastModified(req);
        maybeSetLastModified(resp, lastModified);
        doHead(req, resp);

    // 处理 POST 请求
    } else if (method.equals(METHOD_POST)) {
        // 调用 doPost 方法
        doPost(req, resp);
    } else if (method.equals(METHOD_PUT)) {
        doPut(req, resp);
    } else if (method.equals(METHOD_DELETE)) {
        doDelete(req, resp);
    } else if (method.equals(METHOD_OPTIONS)) {
        doOptions(req,resp);
    } else if (method.equals(METHOD_TRACE)) {
        doTrace(req,resp);
    } else {
        String errMsg = lStrings.getString("http.method_not_implemented");
        Object[] errArgs = new Object[1];
        errArgs[0] = method;
        errMsg = MessageFormat.format(errMsg, errArgs);
        
        resp.sendError(HttpServletResponse.SC_NOT_IMPLEMENTED, errMsg);
    }
}

如上，第一个 service 方法覆盖父类中的抽象方法，并没什么太多逻辑。所有的逻辑集中在第二个 service 方法中，该方法根据请求类型分发请求。我们可以根据需要覆盖指定的处理方法。

以上所述只是 Servlet 规范中的一部分内容，这些内容是和本文相关的内容。对于 Servlet 规范中的其他内容，大家有兴趣可以自己去探索。好了，关于 Servlet 方面的内容，这里先说这么多。

3.2 DispatcherServlet 族谱

我在前面说到，DispatcherServlet 是 Spring MVC 的核心。所以在分析这个类的源码前，我们有必要了解一下它的族谱，也就是继承关系图。如下：

如上图，红色框是 Servlet 中的接口和类，蓝色框中则是 Spring 中的接口和类。关于 Servlet 内容前面已经说过，下面来简单介绍一下蓝色框中的接口和类，我们从最顶层的接口开始。

● Aware

在 Spring 中，Aware 类型的接口用于向 Spring “索要”一些框架中的信息。比如当某个 bean 实现了 ApplicationContextAware 接口时，Spring 在运行时会将当前的 ApplicationContext 实例通过接口方法 setApplicationContext 传给该 bean。下面举个例子说明，这里我写一个 SystemInfo API，通过该 API 返回一些系统信息。代码如下：

@RestController
@RequestMapping("/systeminfo")
public class SystemInfo implements ApplicationContextAware, EnvironmentAware {

    private ApplicationContext applicationContext;

    private Environment environment;

    @Override
    public void setApplicationContext(ApplicationContext applicationContext) throws BeansException {
        System.out.println(applicationContext.getClass());
        this.applicationContext = applicationContext;
    }

    @Override
    public void setEnvironment(Environment environment) {
        this.environment = environment;
    }

    @RequestMapping("/env")
    public String environment() {
        StandardServletEnvironment sse = (StandardServletEnvironment) environment;
        Map<String, Object> envs = sse.getSystemEnvironment();
        StringBuilder sb = new StringBuilder();
        sb.append("-------------------------++ System Environment ++-------------------------\n");

        List<String> list = new ArrayList<>();
        list.addAll(envs.keySet());

        for (int i = 0; i < 5 && i < list.size(); i++) {
            String key = list.get(i);
            Object val = envs.get(key);
            sb.append(String.format("%s = %s\n", key, val.toString()));
        }

        Map<String, Object> props = sse.getSystemProperties();
        sb.append("\n-------------------------++ System Properties ++-------------------------\n");
        list.clear();
        list.addAll(props.keySet());
        for (int i = 0; i < 5 && i < list.size(); i++) {
            String key = list.get(i);
            Object val = props.get(key);
            sb.append(String.format("%s = %s\n", key, val.toString()));
        }

        return sb.toString();
    }

    @RequestMapping("/beans")
    public String listBeans() {
        ListableBeanFactory lbf = applicationContext;
        String[] beanNames = lbf.getBeanDefinitionNames();
        StringBuilder sb = new StringBuilder();
        sb.append("-------------------------++ Bean Info ++-------------------------\n");
        Arrays.stream(beanNames).forEach(beanName -> {
            Object bean = lbf.getBean(beanName);
            sb.append(String.format("beanName  = %s\n", beanName));
            sb.append(String.format("beanClass = %s\n\n", bean.getClass().toString()));
        });

        return sb.toString();
    }
}

如上，SystemInfo 分别实现了 ApplicationContextAware 和 EnvironmentAware 接口，因此它可以在运行时获取到 ApplicationContext 和 Environment 实例。下面我们调一下接口看看结果吧：

如上，我们通过接口拿到了环境变量、配置信息以及容器中所有 bean 的数据。这说明，Spring 在运行时向 SystemInfo 中注入了 ApplicationContext 和 Environment 实例。

● EnvironmentCapable

EnvironmentCapable 仅包含一个方法定义 getEnvironment，通过该方法可以获取到环境变量对象。我们可以将 EnvironmentCapable 和 EnvironmentAware 接口配合使用，比如下面的实例：

public class EnvironmentHolder implements EnvironmentCapable, EnvironmentAware {

    private Environment environment;

    @Override
    public void setEnvironment(Environment environment) {
        this.environment = environment;
    }

    @Override
    public Environment getEnvironment() {
        return environment;
    }
}

● HttpServletBean

HttpServletBean 是 HttpServlet 抽象类的简单拓展。HttpServletBean 覆写了父类中的无参 init 方法，并在该方法中将 ServletConfig 里的配置信息设置到子类对象中，比如 DispatcherServlet。

● FrameworkServlet

FrameworkServlet 是 Spring Web 框架中的一个基础类，该类会在初始化时创建一个容器。同时该类覆写了 doGet、doPost 等方法，并将所有类型的请求委托给 doService 方法去处理。doService 是一个抽象方法，需要子类实现。

● DispatcherServlet

DispatcherServlet 主要的职责相信大家都比较清楚了，即协调各个组件工作。除此之外，DispatcherServlet 还有一个重要的事情要做，即初始化各种组件，比如 HandlerMapping、HandlerAdapter 等。

3.3 DispatcherServlet 源码简析

在第二章中，我们知道了一个 HTTP 请求是怎么样被 DispatcherServlet 处理的。本节，我们从源码的角度对第二章的内容进行补充说明。这里，我们直入主题，直接分析 DispatcherServlet 中的 doDispatch 方法。这里我把请求的处理流程图再贴一遍，大家可以对着流程图阅读源码。

protected void doDispatch(HttpServletRequest request, HttpServletResponse response) throws Exception {
    HttpServletRequest processedRequest = request;
    HandlerExecutionChain mappedHandler = null;
    boolean multipartRequestParsed = false;

    WebAsyncManager asyncManager = WebAsyncUtils.getAsyncManager(request);

    try {
        ModelAndView mv = null;
        Exception dispatchException = null;

        try {
            processedRequest = checkMultipart(request);
            multipartRequestParsed = (processedRequest != request);

            // 获取可处理当前请求的处理器 Handler，对应流程图中的步骤②
            mappedHandler = getHandler(processedRequest);
            if (mappedHandler == null || mappedHandler.getHandler() == null) {
                noHandlerFound(processedRequest, response);
                return;
            }

            // 获取可执行处理器逻辑的适配器 HandlerAdapter，对应步骤③
            HandlerAdapter ha = getHandlerAdapter(mappedHandler.getHandler());

            // 处理 last-modified 消息头
            String method = request.getMethod();
            boolean isGet = "GET".equals(method);
            if (isGet || "HEAD".equals(method)) {
                long lastModified = ha.getLastModified(request, mappedHandler.getHandler());
                if (logger.isDebugEnabled()) {
                    logger.debug("Last-Modified value for [" + getRequestUri(request) + "] is: " + lastModified);
                }
                if (new ServletWebRequest(request, response).checkNotModified(lastModified) && isGet) {
                    return;
                }
            }

            // 执行拦截器 preHandle 方法
            if (!mappedHandler.applyPreHandle(processedRequest, response)) {
                return;
            }

            // 调用处理器逻辑，对应步骤④
            mv = ha.handle(processedRequest, response, mappedHandler.getHandler());

            if (asyncManager.isConcurrentHandlingStarted()) {
                return;
            }

            // 如果 controller 未返回 view 名称，这里生成默认的 view 名称
            applyDefaultViewName(processedRequest, mv);

            // 执行拦截器 preHandle 方法
            mappedHandler.applyPostHandle(processedRequest, response, mv);
        }
        catch (Exception ex) {
            dispatchException = ex;
        }
        catch (Throwable err) {
            dispatchException = new NestedServletException("Handler dispatch failed", err);
        }
        
        // 解析并渲染视图
        processDispatchResult(processedRequest, response, mappedHandler, mv, dispatchException);
    }
    catch (Exception ex) {
        triggerAfterCompletion(processedRequest, response, mappedHandler, ex);
    }
    catch (Throwable err) {
        triggerAfterCompletion(processedRequest, response, mappedHandler,
                new NestedServletException("Handler processing failed", err));
    }
    finally {
        if (asyncManager.isConcurrentHandlingStarted()) {
            // Instead of postHandle and afterCompletion
            if (mappedHandler != null) {
                mappedHandler.applyAfterConcurrentHandlingStarted(processedRequest, response);
            }
        }
        else {
            if (multipartRequestParsed) {
                cleanupMultipart(processedRequest);
            }
        }
    }
}

private void processDispatchResult(HttpServletRequest request, HttpServletResponse response,
        HandlerExecutionChain mappedHandler, ModelAndView mv, Exception exception) throws Exception {

    boolean errorView = false;

    if (exception != null) {
        if (exception instanceof ModelAndViewDefiningException) {
            logger.debug("ModelAndViewDefiningException encountered", exception);
            mv = ((ModelAndViewDefiningException) exception).getModelAndView();
        }
        else {
            Object handler = (mappedHandler != null ? mappedHandler.getHandler() : null);
            mv = processHandlerException(request, response, handler, exception);
            errorView = (mv != null);
        }
    }

    if (mv != null && !mv.wasCleared()) {
        // 渲染视图
        render(mv, request, response);
        if (errorView) {
            WebUtils.clearErrorRequestAttributes(request);
        }
    }
    else {
        if (logger.isDebugEnabled()) {...
    }

    if (WebAsyncUtils.getAsyncManager(request).isConcurrentHandlingStarted()) {
        return;
    }

    if (mappedHandler != null) {
        mappedHandler.triggerAfterCompletion(request, response, null);
    }
}

protected void render(ModelAndView mv, HttpServletRequest request, HttpServletResponse response) throws Exception {
    Locale locale = this.localeResolver.resolveLocale(request);
    response.setLocale(locale);

    View view;
    /*
     * 若 mv 中的 view 是 String 类型，即处理器返回的是模板名称，
     * 这里将其解析为具体的 View 对象
     */ 
    if (mv.isReference()) {
        // 解析视图，对应步骤⑤
        view = resolveViewName(mv.getViewName(), mv.getModelInternal(), locale, request);
        if (view == null) {
            throw new ServletException("Could not resolve view with name '" + mv.getViewName() +
                    "' in servlet with name '" + getServletName() + "'");
        }
    }
    else {
        view = mv.getView();
        if (view == null) {
            throw new ServletException("ModelAndView [" + mv + "] neither contains a view name nor a " +
                    "View object in servlet with name '" + getServletName() + "'");
        }
    }

    if (logger.isDebugEnabled()) {...}
    try {
        if (mv.getStatus() != null) {
            response.setStatus(mv.getStatus().value());
        }
        // 渲染视图，并将结果返回给用户。对应步骤⑥和⑦
        view.render(mv.getModelInternal(), request, response);
    }
    catch (Exception ex) {
        if (logger.isDebugEnabled()) {...}
        throw ex;
    }
}

以上就是 doDispatch 方法的分析过程，我已经做了较为详细的注释，这里就不多说了。需要说明的是，以上只是进行了简单分析，并没有深入分析每个方法调用。大家若有兴趣，可以自己去分析一下 doDispatch 所调用的一些方法，比如 getHandler 和 getHandlerAdapter，这两个方法比较简单。从我最近所分析的源码来看，我个人觉得处理器适配器 RequestMappingHandlerAdapter 应该是 Spring MVC 中最为复杂的一个类。该类用于对 @RequestMapping 注解的方法进行适配。该类的逻辑我暂时没看懂，就不多说了，十分尴尬。关于该类比较详细的分析，大家可以参考《看透Spring MVC》一书。

4.总结

到此，本篇文章的主体内容就说完了。本篇文章从一个请求的旅行过程进行分析，并在分析的过程中补充了 Servlet 和 DispatcherServlet 方面的知识。在最后，从源码的角度分析了 DispatcherServlet 处理请求的过程。总的来算，算是做到了循序渐进。当然，限于个人能力，以上内容可能会有一些讲的不好的地方，这里请大家见谅。同时，也希望大家多多指教。

好了，本篇文章先到这里。谢谢大家的阅读。

参考

• 《看透Spring MVC》- 韩路彪
• 《JSP & Servlet学习笔记》- 林信良

附录：Spring 源码分析文章列表

Ⅰ. IOC

Ⅱ. AOP

Ⅲ. MVC

本文在知识共享许可协议 4.0 下发布，转载需在明显位置处注明出处
作者：coolblog.xyz
本文同步发布在我的个人博客：http://www.coolblog.xyz

来源： 10张图带你深入理解Docker容器和镜像 – DockOne.io

【编者的话】本文用图文并茂的方式介绍了容器、镜像的区别和Docker每个命令后面的技术细节，能够很好的帮助读者深入理解Docker。

【Kubernetes培训通知】DockOne将会于2018年7月13日在上海举办Kubernetes技术培训，培训内容包括：Docker介绍、Docker镜像、网络、存储、容器安全；Kubernetes架构、设计理念、常用对象、网络、存储、网络隔离、服务发现与负载均衡；Kubernetes核心组件、Pod、插件、微服务、云原生、Kubernetes Operator、集群灾备等。同时深圳站培训也已经启动，欢迎咨询。

这篇文章希望能够帮助读者深入理解Docker的命令，还有容器（container）和镜像（image）之间的区别，并深入探讨容器和运行中的容器之间的区别。

当我对Docker技术还是一知半解的时候，我发现理解Docker的命令非常困难。于是，我花了几周的时间来学习Docker的工作原理，更确切地说，是关于Docker统一文件系统（the union file system）的知识，然后回过头来再看Docker的命令，一切变得顺理成章，简单极了。

题外话：就我个人而言，掌握一门技术并合理使用它的最好办法就是深入理解这项技术背后的工作原理。通常情况下，一项新技术的诞生常常会伴随着媒体的大肆宣传和炒作，这使得用户很难看清技术的本质。更确切地说，新技术总是会发明一些新的术语或者隐喻词来帮助宣传，这在初期是非常有帮助的，但是这给技术的原理蒙上了一层砂纸，不利于用户在后期掌握技术的真谛。

Git就是一个很好的例子。我之前不能够很好的使用Git，于是我花了一段时间去学习Git的原理，直到这时，我才真正明白了Git的用法。我坚信只有真正理解Git内部原理的人才能够掌握这个工具。

Image Definition

镜像（Image）就是一堆只读层（read-only layer）的统一视角，也许这个定义有些难以理解，下面的这张图能够帮助读者理解镜像的定义。

从左边我们看到了多个只读层，它们重叠在一起。除了最下面一层，其它层都会有一个指针指向下一层。这些层是Docker内部的实现细节，并且能够在主机（译者注：运行Docker的机器）的文件系统上访问到。统一文件系统（union file system）技术能够将不同的层整合成一个文件系统，为这些层提供了一个统一的视角，这样就隐藏了多层的存在，在用户的角度看来，只存在一个文件系统。我们可以在图片的右边看到这个视角的形式。

你可以在你的主机文件系统上找到有关这些层的文件。需要注意的是，在一个运行中的容器内部，这些层是不可见的。在我的主机上，我发现它们存在于/var/lib/docker/aufs目录下。

sudo tree -L 1 /var/lib/docker/

/var/lib/docker/
├── aufs
├── containers
├── graph
├── init
├── linkgraph.db
├── repositories-aufs
├── tmp
├── trust
└── volumes
7 directories, 2 files

Container Definition

容器（container）的定义和镜像（image）几乎一模一样，也是一堆层的统一视角，唯一区别在于容器的最上面那一层是可读可写的。

细心的读者可能会发现，容器的定义并没有提及容器是否在运行，没错，这是故意的。正是这个发现帮助我理解了很多困惑。

要点：容器 = 镜像 + 读写层。并且容器的定义并没有提及是否要运行容器。

接下来，我们将会讨论运行态容器。

Running Container Definition

一个运行态容器（running container）被定义为一个可读写的统一文件系统加上隔离的进程空间和包含其中的进程。下面这张图片展示了一个运行中的容器。

正是文件系统隔离技术使得Docker成为了一个前途无量的技术。一个容器中的进程可能会对文件进行修改、删除、创建，这些改变都将作用于可读写层（read-write layer）。下面这张图展示了这个行为。

我们可以通过运行以下命令来验证我们上面所说的：

docker run ubuntu touch happiness.txt

即便是这个ubuntu容器不再运行，我们依旧能够在主机的文件系统上找到这个新文件。

find / -name happiness.txt

/var/lib/docker/aufs/diff/860a7b...889/happiness.txt

Image Layer Definition

为了将零星的数据整合起来，我们提出了镜像层（image layer）这个概念。下面的这张图描述了一个镜像层，通过图片我们能够发现一个层并不仅仅包含文件系统的改变，它还能包含了其他重要信息。

元数据（metadata）就是关于这个层的额外信息，它不仅能够让Docker获取运行和构建时的信息，还包括父层的层次信息。需要注意，只读层和读写层都包含元数据。

除此之外，每一层都包括了一个指向父层的指针。如果一个层没有这个指针，说明它处于最底层。

Metadata Location:
我发现在我自己的主机上，镜像层（image layer）的元数据被保存在名为”json”的文件中，比如说：

/var/lib/docker/graph/e809f156dc985.../json

e809f156dc985…就是这层的id

一个容器的元数据好像是被分成了很多文件，但或多或少能够在/var/lib/docker/containers/<id>目录下找到，<id>就是一个可读层的id。这个目录下的文件大多是运行时的数据，比如说网络，日志等等。

全局理解（Tying It All Together）

现在，让我们结合上面提到的实现细节来理解Docker的命令。

docker create <image-id>

docker create 命令为指定的镜像（image）添加了一个可读写层，构成了一个新的容器。注意，这个容器并没有运行。

docker start <container-id>

Docker start命令为容器文件系统创建了一个进程隔离空间。注意，每一个容器只能够有一个进程隔离空间。

docker run <image-id>

看到这个命令，读者通常会有一个疑问：docker start 和 docker run命令有什么区别。

从图片可以看出，docker run 命令先是利用镜像创建了一个容器，然后运行这个容器。这个命令非常的方便，并且隐藏了两个命令的细节，但从另一方面来看，这容易让用户产生误解。

题外话：继续我们之前有关于Git的话题，我认为docker run命令类似于git pull命令。git pull命令就是git fetch 和 git merge两个命令的组合，同样的，docker run就是docker create和docker start两个命令的组合。

docker ps

docker ps 命令会列出所有运行中的容器。这隐藏了非运行态容器的存在，如果想要找出这些容器，我们需要使用下面这个命令。

docker ps –a

docker ps –a命令会列出所有的容器，不管是运行的，还是停止的。

docker images

docker images命令会列出了所有顶层（top-level）镜像。实际上，在这里我们没有办法区分一个镜像和一个只读层，所以我们提出了top-level镜像。只有创建容器时使用的镜像或者是直接pull下来的镜像能被称为顶层（top-level）镜像，并且每一个顶层镜像下面都隐藏了多个镜像层。

docker images –a

docker images –a命令列出了所有的镜像，也可以说是列出了所有的可读层。如果你想要查看某一个image-id下的所有层，可以使用docker history来查看。

docker stop <container-id>

docker stop命令会向运行中的容器发送一个SIGTERM的信号，然后停止所有的进程。

docker kill <container-id>

docker kill 命令向所有运行在容器中的进程发送了一个不友好的SIGKILL信号。

docker pause <container-id>

docker stop和docker kill命令会发送UNIX的信号给运行中的进程，docker pause命令则不一样，它利用了cgroups的特性将运行中的进程空间暂停。具体的内部原理你可以在这里找到：https://www.kernel.org/doc/Doc … m.txt，但是这种方式的不足之处在于发送一个SIGTSTP信号对于进程来说不够简单易懂，以至于不能够让所有进程暂停。

docker rm <container-id>

docker rm命令会移除构成容器的可读写层。注意，这个命令只能对非运行态容器执行。

docker rmi <image-id>

docker rmi 命令会移除构成镜像的一个只读层。你只能够使用docker rmi来移除最顶层（top level layer）（也可以说是镜像），你也可以使用-f参数来强制删除中间的只读层。

docker commit <container-id>

docker commit命令将容器的可读写层转换为一个只读层，这样就把一个容器转换成了不可变的镜像。

docker build

docker build命令非常有趣，它会反复的执行多个命令。

我们从上图可以看到，build命令根据Dockerfile文件中的FROM指令获取到镜像，然后重复地1）run（create和start）、2）修改、3）commit。在循环中的每一步都会生成一个新的层，因此许多新的层会被创建。

docker exec <running-container-id>

docker exec 命令会在运行中的容器执行一个新进程。

docker inspect <container-id> or <image-id>

docker inspect命令会提取出容器或者镜像最顶层的元数据。

docker save <image-id>

docker save命令会创建一个镜像的压缩文件，这个文件能够在另外一个主机的Docker上使用。和export命令不同，这个命令为每一个层都保存了它们的元数据。这个命令只能对镜像生效。

docker export <container-id>

docker export命令创建一个tar文件，并且移除了元数据和不必要的层，将多个层整合成了一个层，只保存了当前统一视角看到的内容（译者注：expoxt后的容器再import到Docker中，通过docker images –tree命令只能看到一个镜像；而save后的镜像则不同，它能够看到这个镜像的历史镜像）。

docker history <image-id>

docker history命令递归地输出指定镜像的历史镜像。

结论

我希望你们能喜欢这篇文章。还有其他许多的命令（pull，search，restart，attach等）我没有提及，但是我相信通过阅读这篇文章，大部分的Docker命令都能够被很好理解。我仅仅学习了Docker两个星期，因此，如果我有什么地方说的不好，欢迎大家指出。

原文链接：Visualizing Docker Containers and Images（翻译：杨润青）

＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝

译者介绍
杨润青，90后博士僧，研究方向是网络和信息安全。

来源： MYSQL查询一周内的数据(最近7天的) – 追着太阳晒 – 博客园

elect * from wap_content where week(created_at) = week(now)

如果你要严格要求是某一年的，那可以这样

查询一天：

select * from table where to_days(column_time) = to_days(now());
select * from table where date(column_time) = curdate(); 

查询一周：

select * from table  where DATE_SUB(CURDATE(), INTERVAL 7 DAY) <= date(column_time);

查询一个月：

select * from table  where DATE_SUB(CURDATE(), INTERVAL INTERVAL 1 MONTH) <= date(column_time);