系统权限控制体系

在 Web 应用开发中，安全一直是非常重要的一个方面。安全虽然属于应用的非功能性需求，但是应该在应用开发的初期就考虑进来。比如我们开放的功能页面需要登录授权之后才能访问，一些功能需要具备特定权限的人才能操作；再比如我们开放了数据API接口，如果不做访问控制，那么任何人都可以调用，当被不法分子操作时将给我们带来巨大的麻烦。那么在Java 整个体系中访问控制是否有一套理论技术支撑呢，我们是否可以做一个通用性的访问控制系统来完成分布式系统架构下的复杂的权限控制？接下来会一一介绍。

访问控制的本质：

系统权限控制 本质上是访问控制（Access Control），那访问控制的本质又是什么呢？其实就是合法的访问受保护的资源，通俗的解释就是“【谁】是否有可以对某个【资源】进行某种【操作】”；可以看出访问控制的三个基本要素：主体（请求实体）、客体（资源实体）、控制策略（属性集合）；

访问控制需要完成的两个任务：

识别和确认访问系统的用户；
决定该用户可以对某一系统资源进行何种类型的访问；

访问控制理论模型：

示意图：

基于RBAC权限模型的常见数据库模型设计：

设计的核心主题: 用户、权限、角色、用户角色、角色权限、用户组、用户组角色、操作审计
阿里巴巴登录鉴权与审计的三驾马车：BUC、ACL、OpLog；

Java常用访问控制框架：

  • JAAS框架：
    • Authentication（鉴别）， Authorization（授权），Accounting（计费）；
    • Java认证和授权服务（Java Authentication and Authorization Service，简称JAAS）
    • 支持的框架：LDAP
    • 特点：面世时间早，使用受限，不建议使用；
  • Spring Security框架
  • Apache Shiro框架

权限系统的演变历史：

1： 标准的JAAS 时代；

J2ee时代，Java提出了标准的鉴权服务，即jaas；通过简单的容器配置和文件配置，通过一个LDAP（可以用数据库，只是效率不高），就可以提供一个极为高效便捷的权限管控服务。这个模式不仅支持页面管控，还支持ejb服务接口管控。其鉴权因为ldap的数倍于数据库的查询效率而无需任何缓存，速度很快。但是伴随着分布式服务化进程，应用的数量无限度增长，这种散落在各个容器的配置给容灾和修改，都带来了极大的挑战，ldap的可读化差，修改和编辑极为不便，当需求一旦个性化超过了树能够表达的模型便很难在适应。并且当ldap的数据爆炸式增长，且呈现28规律时（数据冷热不均），或者如果需要频繁的写ldap，查询效率会陡然下降。虽然这种方式目前并不流行的，但是由于历史原因，还存留着使用这种方式的管控方式，所以我们在Spring Security或者阿里的ACL中都还能看到对JAAS的支持。

2： 单点登录(SSO)+接口鉴权时代；

把分散在各个系统的登录认证服务统一到一个系统中来，统一管控登录授权业务，用户只要在一个系统中登录了，在其它系统中就没必要再次登录了，这就是SSO。简单的实现是登录授权系统部署在一台机器上，不涉登录系统的多机部署，此架构具有单点风险；任何具备高可用思维的架构师都不会允许此风险存在，原因有二：1. 统一登录中心后，SSO成为极为核心的应用，如果SSO系统挂了，那么需要登录的任何服务器都无法正常提供服务；2. 单台机器不具备抵抗登录风暴的能力； 所以SSO系统必须成为集群部署模式。其次，在访问控制模型上，也必须放弃JAAS方式，转而使用RBAC模型；

3： 统一登录（分布式Session） + 接口鉴权时代；

SSO系统集群部署后，面临的首要问题就是Session的共享问题，比如用户在sso-1 机器上登录了，下次访问sso-2机器时，也必须是登录态的。分布式Session使用较多的方案为：Session集中管理；比如阿里巴巴基于Tair 缓存体系的共享session体系tbsession。如果采用了session + cookie的方案，并且服务端集群是多域名共享登录的话，那么还需要提供cookie跨域同步的能力（解决cookie不能跨域的问题）。

展开全文 >>

Taobao SSO 跨域登录过程解析

今年的双十一和双十二已经告一段落，你是否买到了你想要的宝贝呢？我们知道双十一是天猫的主场，双十二是淘宝的主场，你有没有注意到你在登录了淘宝后，访问天猫或者飞猪，你还是处于登录态的，但是我们知道cookie是不能跨域的，那么阿里是如何做到了多域名下的登录态同步呢？接下来我们通过抓包进行请求解析来了解这个过程。

基础知识：

  1. 如果忘了Cookie和Session的区别，那么建议你先回顾一下，可以参考：https://github.com/astaxie/build-web-application-with-golang/blob/master/zh/06.1.md
  2. 如果不知道为什么需要鉴权，为什么需要SSO，为什么需要跨域登录，建议你先阅读上一篇文章“系统权限控制”。

测试过程：

  1. 访问www.taobao.com 请求登录，跳转到 login.taobao.com
  2. 访问 www.tmall.com
  3. 请求页面 https://tmcc.tmall.com/pass.htm
  4. 请求页面 https://login.taobao.com/jump?target=https://tmcc.tmall.com/pass.htm?tbpm=1
  5. 请求页面 https://pass.tmall.com/add?_tb_token_=eef03e35fbe&u......&target=https%3A%2F%2Ftmcc.tmall.com%2Fpass.htm%3Ftbpm%3D1
    • 携带cookie 信息的query string 参数请求 tmall.com域名下的信息，请求添加cookie。
    • 响应中把请求中的cookie信息set 到 浏览器cookie中，以此完成tmall.com域名下的cookie同步；
    • 响应状态未302 重定向到 https://tmcc.tmall.com/pass.htm?tbpm=1
  6. 请求页面https://tmcc.tmall.com/pass.htm?tbpm=1 302 跳转到 https://tmcc.tmall.com/pass.htm

抓包信息：

图中隐藏了非关键请求，比如页面的静态资源等；

同样：

  1. 访问 www.alitrip.com，会同步请求https://ffa.alitrip.com/userInfo.htm的请求
  2. 请求页面https://ffa.alitrip.com/userInfo.htm
  3. 请求页面https://login.taobao.com/jump?target=https%3A%2F%2Fffa.alitrip.com%2FuserIn
  4. 请求页面https://pass.alitrip.com/add?_tb_token_=eef03e35fbe&uss=UtBTusG4
    • 携带cookie 信息的query string 参数请求 alitrip.com 域名下的信息，请求添加cookie
    • 响应中把请求中的cookie信息set 到 浏览器cookie中，以此完成tmall.com域名下的cookie同步;

示意图：

  1. 访问原始url： tmcc.tmall.com
  2. 重定向，访问login.taobao.com/jump
  3. 重定向，访问pass.tmall.com
  4. 重定向，访问原始url（带有同步标识tbpm）
  5. 重定向，访问原始url（去掉同步标识tbpm）

如果我们taobao.com域下没有登录cookie，通过在login.tmall.com页面进行登录，那么cookie的传递是怎么样的呢？
通过测试，发现在请求login.tmall.com的时候会同步请求login.taobao.com然后cookie依然是通过taobao域同步到tmall域名，也就是cookie的同步是单向；

当然，这个过程是正向流程，那退出登录的逆向流程是怎么样的呢？会同步请求login.taobao.com/clear, 通过set-cookie 清楚session cookie（会话cookie），然后进行 302 跳转到 https://pass.tmall.com/clear 进行cookie清理，然后 302 跳转到 https://pass.etao.com/clear 进行cookie清理，然后 302 跳转到https://pass.etao.com/clear 进行 cookie清理，如此重复知道所有域名cookie进行清理完毕。

通过测试发现淘系的系统所有的退出登录都是走login.taobao.com/member/logout.jhtml , 然后通过一些列302 跳转pass系统进行登录态的清理。 登录态在到阿里云、支付宝是不通的,因为阿里云和支付宝的账号体系不一样。

禁用Cookie：

可以看出整个跨域登录依赖的是cookie信息的传递与跨域设置，如果出于安全考虑，我们禁用了cookie，是否还能正常工作呢？经过测试，发现禁用cookie后，跨域自动登录不能正常执行了，跨域请求后对于受限的访问请求还是会自动跳登录。由于设计上没有考虑cookie禁用的情况，淘宝的登录页面竟然无法进入，一直循环跳转登录页面。

分布式Session 的常见解决方案：

  1. 通过cookie进行共享；
  2. 借助第三方进行存储，比如缓存；
  3. 不容服务器之间进行session同步；

这里面涉及到阿里两个重要级产品：tbsession、passcookie。

  1. tbsession：用来解决多应用间session共享存储与同步问题；tbsession采用的是 方法1 + 方法2的结合；
  2. passcookie：用来解决不同域名之间cookie同步的问题，以及决定同步那些cookie；

思考：

问：为什么有了cookie 还需要 session？

答：cookie存储本身具备一些优势，比如信息存储在客户端，分散了资源消耗，cookie可以在客户端进行持久化存储（cookie在客户端分为：Permanent Cookies，Session Cookie）。 主要是只使用cookie作为资源访问的鉴权记录具备不安全性，容易引起CSRF（跨站请求伪造），比如攻击者劫持登录后的cookie信息进行页面操作，此时服务器以为还是用户自身在登录态下的本人操作。当然，只是简单的使用session也并不能彻底解决CSRF，使用session只是把用户的登录态信息保存在服务器端，客户端cookie往往会记录一个JSessionId 用来标识当前会话ID，jsessionid在网络中传输还是存在被劫持的可能性（参考下面的session劫持），所以需要配合响应的解决手段防止CSRF的发生。其次，cookie的使用在大小和条数上限制，大于需要存储大量用户态信息的场景下已经不够用了，此时需要借助session在服务端的存储设备来实现。

问：登录后会会话中的每一次访问受限资源都需要访问验证？

答：是的，因为每一次请求都无法确认你的身份，所以为了降低复杂认证授权的过程，通过sessionId 来标识某一会话；如果我们的Cookie信息泄露，那么不法分子就可以使用我们包含登录态的Cookie进行访问我们的受限资源（比如拷贝登录后的cookie信息通过postman请求需要登录后才能查看的信息），即便是我们丢增删改的请求采用了crsf_token ,不法分子还是可以看到我们的信息，信息已经造成了泄露。所以对于持久化Cookie，尽量设置为httpOnly，不允许通过JS脚本读取Cookie信息。还有就是使用https协议代替http协议（从tcp到ssl），这样不法分子劫持了请求信息，也无法破解请求信息的内容。

问：是否采用了https就不需要防范CSRF了？

答：不是的，我们采用https，是在数据传输层对请求进行进行加密后发送，但是如果CSRF是在浏览器的本地读取我们的Cookie信息（存储在我们浏览器中本地的Cookie信息确实明文的），还是可以读取到我们明文的Cookie信息。采用https只是防止了请求在传输中拦截后窃取我们的Cookie进行攻击而已。

Session 劫持与防范：

这篇文章详细阐述了服务器端不做任何处理下的sessionId劫持的案例。
https://github.com/astaxie/build-web-application-with-golang/blob/master/zh/06.4.md

session 劫持的防范措施：

  1. 使用POST 请求 + Referer验证；
    • 此方式简单容易实现；
    • 弊端：1.所有请求都是用POST方式不符合规范，比如RestFul。2.很多场景下请求是无法携带referer的；
  2. 使用csrf_token：在涉及增删改的请求中，带上一个和服务器端同步的随机数(token)，然后在服务器端做校验。由于这个token是变化的，同时具有私密性，只会内嵌到当前用户的页面中，因此可以起到防止CSRF的作用，比如淘宝域下cookie中的_tb_token_参数。

csrftoken的整个生命周期一般是这样的：

  • 后端针对每一个用户生成唯一的csrftoken后
  • 将csrftoken存储在服务器端，且和当前用户一一绑定
  • 当用户访问页面时，将csrftoken埋入前端页面
  • 用户提交请求时，需要在请求中附带上csrftoken
  • 后端对接收到的csrftoken进行校验，判断请求是否合法
  • 根据请求，后端判断是非需要更新csrftoken

使用csrf_token 方案目前来说是最有效的安全措施，但是方案实施起来也相对复杂很多，需要考虑csrf_token的存储、更新、埋点以及校验等逻辑。

本质思考：

SSO 跨域统一登录的本质就是【登录态信息的跨域共享，为了实现共享采用了复制的方式】，这跟我们现实世界中为了达到知识共享，需要把知识转化为书籍，然后通过书籍印刷进行分发。

抓包工具介绍：

  1. 工具采用 mac 下的 Charles；
  2. https由于安全限制无法抓取到具体的内容，所以需要通过一些列的设置才能抓到请求数据；
  3. Charles -> Help -> SSL Proxying -> Install Charles Root Certificate
  4. Proxy -> SSL Proxying Setting -> SSL Proxying 添加正则域名

展开全文 >>

二零一七，我的失败与伟大

2017年飘然离去，留下的唯有回忆。这一年总有一些刻骨铭心，总有一些难以忘怀，依依不舍。或遗落在某一渡口，或消失在某段站台，或模糊在某页书籍。岁月洗礼而后，一一封存，装帧成册，遗忘的森林，层出不穷的景致，黯淡了记忆的门窗。当又一次轻扣，忽而想起那年夏天的故事，亦或冬天里的恋歌，轻捻时光，掀开了往事，撑开了回忆的帆。这一年有过痛苦、焦虑、烦躁，也有过欢乐，自信和拼搏。

如果说让我用一句话总结一下2017年，我想这句话会比较合适：

认知上升了一个台阶，但仍未能克服行为上的懒惰；工作生活，持续反思与学习，但仍沉溺于专业深度的自卑之中。

如果非要让我从过去一年中对自己的失败和伟大之处做一些“套路”上的总结的话，以下这几天应该被展现出来，愿它们像伴随我成长之路上的路灯，时时照亮我前行的路。

1. 认知升级，追本溯源

这一年自己思想的改变应该算是最大的收获了。以前对待事情总是浮在表面，现在会主动去思考事情背后的关系与本质，到底是什么导致了当前的状态，每个人说的话其背后的逻辑是什么；比如当开会、讨论、看演讲时，都会跳出当前讨论的事情，去想他们为什么会这么说，理论基础是什么，期望达到一个什么目标。

近期通过研究高效学习的理论知识，逐步掌握学习知识的方法套路。学习的理论自己在高中和大学阶段坚持的不错，但是工作以来，坚持的并不算好，很多时候，一天过去了，回顾时，是浑浑噩噩的，对自己的人生似乎帮助并不大，感慨自己的浪费生命。记得之前看到过一句话，我们现在做的觉得有挑战的事情，之前已经有很多人应该都做过了，我们只需要看看他们踩过的吭和趟出的路就好的。这点无论是放在编程还是人生上来说，都适用。很多时候，我们不需要重复造轮子，有轮子直接购买使用就好，为自己的工作生活快速提效，这是一个一切为“效率”为核心的时代。

什么是认知升级，就是看到了之前自己看不到的地方，看问题的角度比之前上升了一个角度。如果把认知划分为本能层、情绪层、立场层、利益层、社会心理层、系统认知层和智慧认知层的话，我目前只能算是从本能层走到了情绪层，未来的路还有很多要走。


​ （图片来自“雾满拦江”）

什么是认知，什么是格局，我觉得有一个例子很不错，值得自己记在心里：

《吕氏套秋》里记载着一则楚王失弓的故事，讲的是楚王去云梦泽打猎，不小心把自己心爱的弓丢了，侍从们要循原路寻找，楚王说，算了吧，不必去找了，楚人失之，楚人得之，到不了别处的。侍从们都很佩服楚王的豁达与胸怀。孔子听闻此事后说，这句话如果去掉“楚”字就好了，不妨说“人失之，人得之。”老子听说了孔子的评论后，也发表了自己的看法。他说再去掉“人”字会更好。那样就是“失之，得之”，这样才符合天道。

2. 把握自己的命运，不要把自己的未来寄托在别人手上

相信炒股的朋友都收到过推销内幕股的电话或者微信，他们通过前一天收盘后的预期与第二天开盘后的涨幅逐步获取你的信任，之后采用盈利分成或者入会费的方式，跟你合作，告诉你什么时间点买哪只股票，什么价位卖出。开始的时候，我确实在短时间内赚了好几千快，感觉他们太牛了，感觉这种赚钱方式比工作快多了，无法克制住自己的贪婪，投入大量的资金进去，此时一次正常的下跌也让我们损失惨重，炒作垃圾股，根本就没有持仓的信心。跳出来好好想一想，如果钱真的这么好赚，他们为什么还要花这么大的心思跟你分成呢？他们过分强调了平分你的收益而把风险完全抛给了你。其次，走位一个多年的老股票，完全听信一个不知专业深浅的人指导，这跟板上鱼肉有何区别呢？即使是赚了钱，你也获取不到技能的提升，对于你后续的投资思路不会有半毛钱帮助，有的只有那点钱了。

正确的投资股市方式是建立其自己投资模式，比如改“投机”为“投资”，注重收益与风险的管理，做优质企业的中长线价值投资等。

其次，这点在个人职业生涯中同样适用，我们伴随着团队成长的同时，也要明确知道自己在职业这个坐标体系中自己的位置，明确自己的目标坐标，通过资源争取或者个人努力，逐渐向目标靠拢，而不是等待着老板或者同事赶着你走。如果事事都是你的老板说了算，你自己没有主见的话，这跟被牵着鼻子走的牛没什么两样，在团队中，你也只能成为“老黄牛”了，当你老了，结果会是“卸磨杀驴”（2017年华为清退老员工事件）。反观自己，以前很少与老板探讨自己想要什么，不要做什么，现在有一定的自信说出自己的诉求，然后主动把握机会磨练自己的独特优势，这一点是一个进步。

3. 矫正心理饥饿的金钱观

由于自己出生在一个比较贫困的家庭，自幼对金钱就分外珍惜，什么钱都不舍得花，甚至认为除了基本保证生活的开支外，一切的花销都是多余的。很多人看到这点肯定会评价说是“抠门”，我们不能拿着自己优越的生活去评论不曾经历的贫穷生活，因为你想象不到，贫穷深入骨髓后是一种什么状态。每当在相亲节目中看到那些抠门的男方的时候，我都很难能理解，然而面对确实大家一边倒式的批判。改革开放40年来，人们的生活质量有了非常的提升，但是很多的养成的节省系统并不是说改掉就能改掉的，就像我父母，他们年幼时经历了大饥荒，知道现在全家年收入超过已经达到小康水平，但还每日担忧未来可能没有饭吃，非要在自家的储藏室中储藏上几袋大米，心理才有安全感，其实这个陈为“心理饥饿”。由于害怕失去钱，害怕自己变得一无所有，所以自己万事都尽量已保守节省的方式在生活，殊不知，在现代经济中，反而认为最安全的方式往往却是最危险的方式，比如父母为了少还一些利息，买房时尽量不让贷款，几乎全款买房，殊不知，合理负债才是家庭财务经营的正确指导。

这个世界正在以超乎我们想象的速度变化，如果我们还保守着过去看似正确的理念生活，那么我们会与优质生活质量相差越来越远。钱是用来花的，不是用来存储的，学会花钱也是一门艺术。合理的消费，不仅有助于提高自身生活质量，还能提高国家的经济效应。现在的我不在为一周多买一次水果而大呼小叫，不再为每餐两人三菜而觉得浪费，为了让自己生活有点品质，还是不是给家里买一些鲜花来装饰装饰，美好的生活反过来会对我们的工作行程正反馈，心情好了，工作效率也会高不少。

自从买了车之后，生活确实变得不一样了，说走就走的旅行变得不再那么困难，自驾游去千岛湖，飞行去昆明、丽江、大理和香格里拉，感受祖国的大美河山和不同的乡土文化，读千卷书，行万里路。世界这么大大，我们应该时长走出去看看，走出工作家庭两点一线之间的线性单调区间。

4. 为专业付费，免费的往往是最贵的

互联网在过去5年，倡导的一直是“免费”的文化，让产品免费，让更多用户受益。我们在使用各种软件或者观看各种收费视频的时候，首先先到的是找一找有没有破解版或者不需要收费的服务，为了获得免费的东西，有时候我们花费了大量的时间和精力，事后想一想，如果把时间换算成钱的话，我们是亏了的。往往看似免费的东西是最贵的，这个世界上没有免费的午餐，一切事情都是有成本的，只是有些事情的成本是隐形的，不容易被我们察觉罢了。免费的东西，人人都能力，其质量就很差，我们长期阅读低质的信息，会阻碍我们思维升级。反而那些付费的内容，正因为我们的付费，才促就了内容生产者以更加严谨的态度来对待产品，这是一个良性循环。我们值得为优质内容付费，科学高效的方法论告诉我们，跟随业界一流的牛人学习，才是高效的学习策略之一。

5. 你的圈子决定了你的价值

查尔斯琼斯说：通过一个人的朋友圈和他看的书就可以看到5年以后的他，也就是说呢，一个人是他周围5个人的综合体。从而形成了“五次元密友理论”。环境的力量，我们不得不信服。古代有孟母三迁，现代人为了一套学区房挤破脑袋。跟优秀的人在一起，我们会被优秀的气场所影响，观念、行为也逐步会发生改变。

所以很多成功学或者心灵鸡汤类的文章常常建议我们每年主动与比我们自身段位高的人的人交往与交流，虽然在我们与他们交往中会有一定的不适感，但我们需要认识到这是正常的生理反应，是突破舒适区的副作用，我们终究会逐渐习惯，这种不适感会随着我们段位的提升而逐渐消失。

反观身边那些职场中晋升非常快的人，在他们成长的路上，几乎都有一个伙伴，和他们一起成长，帮助他们坚持正确的决定，从而避开错误。一个好的有责任心的伙伴是这样的，无条件的爱你，他本身就渴望成功，成熟，会征求你的建议，在你需要帮助的时候能帮助你，能够陪伴鼓励你！你是不能一个人在成长的道路上走下去的，除非你不想达到顶峰。在看看自己当前身处的环境，是否有这样一个伙伴一同成长，如果没有，我们改如何破局？

6. 感悟人性

狗为什么会对陌生人狂吠，人为什么会对伤害自身利益的言论会极力反驳进而情绪失控？面对巨大利益的时候，我们为什么会贪婪？这些都跟本性有关，了解人性，对我们日常生活非常有帮助，无论是我们做投资还是与人相处。就好像，以前老婆跟我抱怨工作上的不顺利，每次在她还没有说完前，我就不耐烦的打断，一口要求都是你自己的错误，在无法改变别人的前提下，你为什么不改变自己呢，然后噼里啪啦的堆砌出一大推自认为很有哲理性的说教语句，换来的结果总是无话可说。当我知晓了这背后的人性需求后，从说教着改为倾听者、陪伴者，效果一下子就不一样了。人性，是需要持续学习和感悟的东西，未来我会花时间系统性的去了解人性的心理学体系。

7. 成为一名佛系青年

去了一趟香格里拉，接触藏民后，彻底改变了我对藏民和佛教的看法。认知中，藏M是野蛮和暴利的代名词，佛教是无知的人期望佛教来改变自身命运，现在看来，原来自己如井底之蛙般视野短浅，认知还停留在本能层。在一名叫做“幸福哥”的藏M导游解说藏传佛教的信仰之时，自己不知不觉中流下了真诚而感动的泪水。回来的途中，阅读了鬼脚七的《人生所有经过的路，都是必经之路》，感受他在出嫁求佛路中的点滴感悟，领悟颇多，自此下定决心，没事就开始背诵和抄写心经。佛教教会我们如何看待自己和这个世界，这个视角是脱离自我的视角，是以更高层的认识来看到实物的视角；比如“画外看画”，脱离自我，站在旁观者角度审视自己的举止言行，我们会有不一样的思考。

在工作生活中，我也不断践行佛教的自我审视的方法，遇到不开心的或者困惑的事情，也尝试着使用佛教中思想来指导言行，虽然有些时候还是不能控制住自己的身为人的本性，但是我相信，通过不断的练习，终究会抵达彼岸，菩提萨婆诃。

8. 让自己成为有一技之长的专业人才

身为一名软件工程师，但是迟迟没有专业自信，究其原因，是因为自己在专业性上的精力投入远远不够，由于积累的太薄，很多技术都不说不清其核心思想，当面对未知的问题时，顿时会觉得恐慌和无助，更不要谈自信了。如何成为专业的人才，方法和策略其实自己都已知晓，但是迟迟未能行动，即便是行动起来了，也是三天打鱼两天晒网。这是一个道理过剩，行动力匮乏的年代，我们不会因为知道了变得不一样，而会因我们做了什么而不一样。以此祭奠我过去5年的专业自卑感，计划用一到两年时间来培养自己的专业自信。

9. 认清自己的核心优势，差异化竞争

总觉得自己啥都能干，但是啥都不专业。在面对当前追求效率的社会大浪潮中，分工越来越细化，我们必须清楚的自己在社会大分工中位置，知道自己相比于其他人有哪些优势，短板在哪里，如何发挥个人的差异化竞争。最近在招聘中，对于那些什么都能干，然后什么研究的都不深入，有没有任何亮点的同学，我们基本都会直接Pass掉。我们常常笑道：如果按照现在的标准，我们也许都面不过当前的岗位。

展开全文 >>

The Twelve-Factor App

简介

如今，软件通常会作为一种服务来交付，它们被称为网络应用程序，或软件即服务（SaaS）。12-Factor 为构建如下的 SaaS 应用提供了方法论：

  • 使用标准化流程自动配置，从而使新的开发者花费最少的学习成本加入这个项目。
  • 和操作系统之间尽可能的划清界限，在各个系统中提供最大的可移植性。
  • 适合部署在现代的云计算平台，从而在服务器和系统管理方面节省资源。
  • 将开发环境和生产环境的差异降至最低，并使用持续交付实施敏捷开发。
  • 可以在工具、架构和开发流程不发生明显变化的前提下实现扩展。
  • 这套理论适用于任意语言和后端服务（数据库、消息队列、缓存等）开发的应用程序。

背景

本文的贡献者者参与过数以百计的应用程序的开发和部署，并通过 Heroku 平台间接见证了数十万应用程序的开发，运作以及扩展的过程。

本文综合了我们关于 SaaS 应用几乎所有的经验和智慧，是开发此类应用的理想实践标准，并特别关注于应用程序如何保持良性成长，开发者之间如何进行有效的代码协作，以及如何 避免软件污染 。

我们的初衷是分享在现代软件开发过程中发现的一些系统性问题，并加深对这些问题的认识。我们提供了讨论这些问题时所需的共享词汇，同时使用相关术语给出一套针对这些问题的广义解决方案。本文格式的灵感来自于 Martin Fowler 的书籍： Patterns of Enterprise Application Architecture ， Refactoring 。

读者应该是哪些人？

任何 SaaS 应用的开发人员。部署和管理此类应用的运维工程师。

12-factors

I. 基准代码

一份基准代码（Codebase），多份部署（deploy）
12-Factor应用(译者注：应该是说一个使用本文概念来设计的应用，下同)通常会使用版本控制系统加以管理，如Git, Mercurial, Subversion。一份用来跟踪代码所有修订版本的数据库被称作 代码库（code repository, code repo, repo）。

在类似 SVN 这样的集中式版本控制系统中，基准代码 就是指控制系统中的这一份代码库；而在 Git 那样的分布式版本控制系统中，基准代码 则是指最上游的那份代码库。

基准代码和应用之间总是保持一一对应的关系：

  • 一旦有多个基准代码，就不能称为一个应用，而是一个分布式系统。分布式系统中的每一个组件都是一个应用，每一个应用可以分别使用 12-Factor 进行开发。
  • 多个应用共享一份基准代码是有悖于 12-Factor 原则的。解决方案是将共享的代码拆分为独立的类库，然后使用 依赖管理 策略去加载它们。

尽管每个应用只对应一份基准代码，但可以同时存在多份部署。每份 部署 相当于运行了一个应用的实例。通常会有一个生产环境，一个或多个预发布环境。此外，每个开发人员都会在自己本地环境运行一个应用实例，这些都相当于一份部署。

所有部署的基准代码相同，但每份部署可以使用其不同的版本。比如，开发人员可能有一些提交还没有同步至预发布环境；预发布环境也有一些提交没有同步至生产环境。但它们都共享一份基准代码，我们就认为它们只是相同应用的不同部署而已。

II. 依赖

显式声明依赖关系（ dependency ）
大多数编程语言都会提供一个打包系统，用来为各个类库提供打包服务，就像 Perl 的 CPAN 或是 Ruby 的 Rubygems 。通过打包系统安装的类库可以是系统级的（称之为 “site packages”），或仅供某个应用程序使用，部署在相应的目录中（称之为 “vendoring” 或 “bunding”）。

12-Factor规则下的应用程序不会隐式依赖系统级的类库。 它一定通过 依赖清单 ，确切地声明所有依赖项。此外，在运行过程中通过 依赖隔离 工具来确保程序不会调用系统中存在但清单中未声明的依赖项。这一做法会统一应用到生产和开发环境。

例如， Ruby 的 Bundler 使用 Gemfile 作为依赖项声明清单，使用 bundle exec 来进行依赖隔离。Python 中则可分别使用两种工具 – Pip 用作依赖声明， Virtualenv 用作依赖隔离。甚至 C 语言也有类似工具， Autoconf 用作依赖声明，静态链接库用作依赖隔离。无论用什么工具，依赖声明和依赖隔离必须一起使用，否则无法满足 12-Factor 规范。

显式声明依赖的优点之一是为新进开发者简化了环境配置流程。新进开发者可以检出应用程序的基准代码，安装编程语言环境和它对应的依赖管理工具，只需通过一个 构建命令 来安装所有的依赖项，即可开始工作。例如，Ruby/Bundler 下使用 bundle install，而 Clojure/Leiningen 则是 lein deps。

12-Factor 应用同样不会隐式依赖某些系统工具，如 ImageMagick 或是curl。即使这些工具存在于几乎所有系统，但终究无法保证所有未来的系统都能支持应用顺利运行，或是能够和应用兼容。如果应用必须使用到某些系统工具，那么这些工具应该被包含在应用之中。

III. 配置

在环境中存储配置
通常，应用的 配置 在不同 部署 (预发布、生产环境、开发环境等等)间会有很大差异。这其中包括：

  • 数据库，Memcached，以及其他 后端服务 的配置
  • 第三方服务的证书，如 Amazon S3、Twitter 等
  • 每份部署特有的配置，如域名等

有些应用在代码中使用常量保存配置，这与 12-Factor 所要求的代码和配置严格分离显然大相径庭。配置文件在各部署间存在大幅差异，代码却完全一致。

判断一个应用是否正确地将配置排除在代码之外，一个简单的方法是看该应用的基准代码是否可以立刻开源，而不用担心会暴露任何敏感的信息。

需要指出的是，这里定义的“配置”并不包括应用的内部配置，比如 Rails 的 config/routes.rb，或是使用 Spring 时 代码模块间的依赖注入关系 。这类配置在不同部署间不存在差异，所以应该写入代码。

另外一个解决方法是使用配置文件，但不把它们纳入版本控制系统，就像 Rails 的 config/database.yml 。这相对于在代码中使用常量已经是长足进步，但仍然有缺点：总是会不小心将配置文件签入了代码库；配置文件的可能会分散在不同的目录，并有着不同的格式，这让找出一个地方来统一管理所有配置变的不太现实。更糟的是，这些格式通常是语言或框架特定的。

12-Factor推荐将应用的配置存储于 环境变量 中（ env vars, env ）。环境变量可以非常方便地在不同的部署间做修改，却不动一行代码；与配置文件不同，不小心把它们签入代码库的概率微乎其微；与一些传统的解决配置问题的机制（比如 Java 的属性配置文件）相比，环境变量与语言和系统无关。

配置管理的另一个方面是分组。有时应用会将配置按照特定部署进行分组（或叫做“环境”），例如Rails中的 development,test, 和 production 环境。这种方法无法轻易扩展：更多部署意味着更多新的环境，例如 staging或 qa 。 随着项目的不断深入，开发人员可能还会添加他们自己的环境，比如 joes-staging ，这将导致各种配置组合的激增，从而给管理部署增加了很多不确定因素。

12-Factor 应用中，环境变量的粒度要足够小，且相对独立。它们永远也不会组合成一个所谓的“环境”，而是独立存在于每个部署之中。当应用程序不断扩展，需要更多种类的部署时，这种配置管理方式能够做到平滑过渡。

IV. 后端服务

把后端服务(backing services)当作附加资源
后端服务是指程序运行所需要的通过网络调用的各种服务，如数据库（MySQL，CouchDB），消息/队列系统（RabbitMQ，Beanstalkd），SMTP 邮件发送服务（Postfix），以及缓存系统（Memcached）。

类似数据库的后端服务，通常由部署应用程序的系统管理员一起管理。除了本地服务之外，应用程序有可能使用了第三方发布和管理的服务。示例包括 SMTP（例如 Postmark），数据收集服务（例如 New Relic 或 Loggly），数据存储服务（如 Amazon S3），以及使用 API 访问的服务（例如 Twitter, Google Maps, Last.fm）。

12-Factor 应用不会区别对待本地或第三方服务。 对应用程序而言，两种都是附加资源，通过一个 url 或是其他存储在 配置 中的服务定位/服务证书来获取数据。12-Factor 应用的任意 部署 ，都应该可以在不进行任何代码改动的情况下，将本地 MySQL 数据库换成第三方服务（例如 Amazon RDS）。类似的，本地 SMTP 服务应该也可以和第三方 SMTP 服务（例如 Postmark ）互换。上述 2 个例子中，仅需修改配置中的资源地址。

每个不同的后端服务是一份 资源 。例如，一个 MySQL 数据库是一个资源，两个 MySQL 数据库（用来数据分区）就被当作是 2 个不同的资源。12-Factor 应用将这些数据库都视作 附加资源 ，这些资源和它们附属的部署保持松耦合。

部署可以按需加载或卸载资源## 部署可以按需加载或卸载资源部署可以按需加载或卸载资源部署可以按需加载或卸载资源。例如，如果应用的数据库服务由于硬件问题出现异常，管理员可以从最近的备份中恢复一个数据库，卸载当前的数据库，然后加载新的数据库 – 整个过程都不需要修改代码。

V. 构建，发布，运行

严格分离构建和运行

基准代码 转化为一份部署(非开发环境)需要以下三个阶段：

  • 构建阶段 是指将代码仓库转化为可执行包的过程。构建时会使用指定版本的代码，获取和打包 依赖项，编译成二进制文件和资源文件。
  • 发布阶段 会将构建的结果和当前部署所需 配置 相结合，并能够立刻在运行环境中投入使用。
  • 运行阶段 （或者说“运行时”）是指针对选定的发布版本，在执行环境中启动一系列应用程序 进程。

12-factor 应用严格区分构建，发布，运行这三个步骤。 举例来说，直接修改处于运行状态的代码是非常不可取的做法，因为这些修改很难再同步回构建步骤。

部署工具通常都提供了发布管理工具，最引人注目的功能是退回至较旧的发布版本。比如， Capistrano 将所有发布版本都存储在一个叫 releases 的子目录中，当前的在线版本只需映射至对应的目录即可。该工具的 rollback 命令可以很容易地实现回退版本的功能。

每一个发布版本必须对应一个唯一的发布 ID，例如可以使用发布时的时间戳（2011-04-06-20:32:17），亦或是一个增长的数字（v100）。发布的版本就像一本只能追加的账本，一旦发布就不可修改，任何的变动都应该产生一个新的发布版本。

新的代码在部署之前，需要开发人员触发构建操作。但是，运行阶段不一定需要人为触发，而是可以自动进行。如服务器重启，或是进程管理器重启了一个崩溃的进程。因此，运行阶段应该保持尽可能少的模块，这样假设半夜发生系统故障而开发人员又捉襟见肘也不会引起太大问题。构建阶段是可以相对复杂一些的，因为错误信息能够立刻展示在开发人员面前，从而得到妥善处理。

VI. 进程

以一个或多个无状态进程运行应用
运行环境中，应用程序通常是以一个和多个 进程 运行的。

最简单的场景中，代码是一个独立的脚本，运行环境是开发人员自己的笔记本电脑，进程由一条命令行（例如python my_script.py）。另外一个极端情况是，复杂的应用可能会使用很多 进程类型 ，也就是零个或多个进程实例。

12-Factor 应用的进程必须无状态且 无共享 。 任何需要持久化的数据都要存储在 后端服务 内，比如数据库。

内存区域或磁盘空间可以作为进程在做某种事务型操作时的缓存，例如下载一个很大的文件，对其操作并将结果写入数据库的过程。12-Factor应用根本不用考虑这些缓存的内容是不是可以保留给之后的请求来使用，这是因为应用启动了多种类型的进程，将来的请求多半会由其他进程来服务。即使在只有一个进程的情形下，先前保存的数据（内存或文件系统中）也会因为重启（如代码部署、配置更改、或运行环境将进程调度至另一个物理区域执行）而丢失。

源文件打包工具（Jammit, django-compressor） 使用文件系统来缓存编译过的源文件。12-Factor 应用更倾向于在 构建步骤做此动作——正如 Rails资源管道 ，而不是在运行阶段。

一些互联网系统依赖于 “粘性 session”， 这是指将用户 session 中的数据缓存至某进程的内存中，并将同一用户的后续请求路由到同一个进程。粘性 session 是 12-Factor 极力反对的。Session 中的数据应该保存在诸如 Memcached 或 Redis 这样的带有过期时间的缓存中。

VII. 端口绑定

通过端口绑定(Port binding)来提供服务
互联网应用有时会运行于服务器的容器之中。例如 PHP 经常作为 Apache HTTPD 的一个模块来运行，正如 Java 运行于 Tomcat 。

12-Factor 应用完全自我加载 而不依赖于任何网络服务器就可以创建一个面向网络的服务。互联网应用 通过端口绑定来提供服务 ，并监听发送至该端口的请求。

本地环境中，开发人员通过类似http://localhost:5000/的地址来访问服务。在线上环境中，请求统一发送至公共域名而后路由至绑定了端口的网络进程。

通常的实现思路是，将网络服务器类库通过 依赖声明 载入应用。例如，Python 的 Tornado, Ruby 的Thin , Java 以及其他基于 JVM 语言的 Jetty。完全由 用户端 ，确切的说应该是应用的代码，发起请求。和运行环境约定好绑定的端口即可处理这些请求。

HTTP 并不是唯一一个可以由端口绑定提供的服务。其实几乎所有服务器软件都可以通过进程绑定端口来等待请求。例如，使用 XMPP 的 ejabberd ， 以及使用 Redis 协议 的 Redis 。

还要指出的是，端口绑定这种方式也意味着一个应用可以成为另外一个应用的 后端服务 ，调用方将服务方提供的相应 URL 当作资源存入 配置 以备将来调用。

VIII. 并发

通过进程模型进行扩展
任何计算机程序，一旦启动，就会生成一个或多个进程。互联网应用采用多种进程运行方式。例如，PHP 进程作为 Apache 的子进程存在，随请求按需启动。Java 进程则采取了相反的方式，在程序启动之初 JVM 就提供了一个超级进程储备了大量的系统资源(CPU 和内存)，并通过多线程实现内部的并发管理。上述 2 个例子中，进程是开发人员可以操作的最小单位。

扩展表现为运行中的进程，工作多样性表现为进程类型。

在 12-factor 应用中，进程是一等公民。12-Factor 应用的进程主要借鉴于 unix 守护进程模型 。开发人员可以运用这个模型去设计应用架构，将不同的工作分配给不同的 进程类型 。例如，HTTP 请求可以交给 web 进程来处理，而常驻的后台工作则交由 worker 进程负责。

这并不包括个别较为特殊的进程，例如通过虚拟机的线程处理并发的内部运算，或是使用诸如 EventMachine, Twisted, Node.js 的异步/事件触发模型。但一台独立的虚拟机的扩展有瓶颈（垂直扩展），所以应用程序必须可以在多台物理机器间跨进程工作。

上述进程模型会在系统急需扩展时大放异彩。 12-Factor 应用的进程所具备的无共享，水平分区的特性 意味着添加并发会变得简单而稳妥。这些进程的类型以及每个类型中进程的数量就被称作 进程构成 。

12-Factor 应用的进程 不需要守护进程 或是写入 PID 文件。相反的，应该借助操作系统的进程管理器(例如 systemd ，分布式的进程管理云平台，或是类似 Foreman 的工具)，来管理 输出流 ，响应崩溃的进程，以及处理用户触发的重启和关闭超级进程的请求。

IX. 易处理

快速启动和优雅终止可最大化健壮性
12-Factor 应用的 进程 是 易处理（disposable）的，意思是说它们可以瞬间开启或停止。 这有利于快速、弹性的伸缩应用，迅速部署变化的 代码 或 配置 ，稳健的部署应用。

进程应当追求 最小启动时间 。 理想状态下，进程从敲下命令到真正启动并等待请求的时间应该只需很短的时间。更少的启动时间提供了更敏捷的 发布 以及扩展过程，此外还增加了健壮性，因为进程管理器可以在授权情形下容易的将进程搬到新的物理机器上。

进程 一旦接收 终止信号（SIGTERM） 就会优雅的终止 。就网络进程而言，优雅终止是指停止监听服务的端口，即拒绝所有新的请求，并继续执行当前已接收的请求，然后退出。此类型的进程所隐含的要求是HTTP请求大多都很短(不会超过几秒钟)，而在长时间轮询中，客户端在丢失连接后应该马上尝试重连。

对于 worker 进程来说，优雅终止是指将当前任务退回队列。例如，RabbitMQ 中，worker 可以发送一个NACK信号。 Beanstalkd 中，任务终止并退回队列会在worker断开时自动触发。有锁机制的系统诸如 Delayed Job 则需要确定释放了系统资源。此类型的进程所隐含的要求是，任务都应该 可重复执行 ， 这主要由将结果包装进事务或是使重复操作 幂等 来实现。

进程还应当在面对突然死亡时保持健壮，例如底层硬件故障。虽然这种情况比起优雅终止来说少之又少，但终究有可能发生。一种推荐的方式是使用一个健壮的后端队列，例如 Beanstalkd ，它可以在客户端断开或超时后自动退回任务。无论如何，12-Factor 应用都应该可以设计能够应对意外的、不优雅的终结。Crash-only design 将这种概念转化为 合乎逻辑的理论。

X. 开发环境与线上环境等价

尽可能的保持开发，预发布，线上环境相同
从以往经验来看，开发环境（* 从以往经验来看，开发环境（即开发人员的本地 部署）和线上环境（外部用户访问的真实部署）之间存在着很多差异。这些差异表现在以下三个方面：

  • 时间差异： 开发人员正在编写的代码可能需要几天，几周，甚至几个月才会上线。
  • 人员差异： 开发人员编写代码，运维人员部署代码。
  • 工具差异： 开发人员或许使用 Nginx，SQLite，OS X，而线上环境使用 Apache，MySQL 以及 Linux。

想要做到 持续部署 就必须* 想要做到 持续部署 就必须缩小本地与线上差异。 再回头看上面所描述的三个差异:

  • 缩小时间差异：开发人员可以几小时，甚至几分钟就部署代码。
  • 缩小人员差异：开发人员不只要编写代码，更应该密切参与部署过程以及代码在线上的表现。
  • 缩小工具差异：尽量保证开发环境以及线上环境的一致性。

将上述总结变为一个表格如下：

传统应用 12-FACTOR 应用
每次部署间隔 数周 几小时
开发人员 VS 运维人员 不同的人 相同的人
开发环境 VS 线上环境 不同 尽量接近
后端服务 是保持开发与线上等价的重要部分，例如数据库，队列系统，以及缓存。许多语言都提供了简化获取后端服务的类库，例如不同类型服务的 适配器 。下列表格提供了一些例子。

类型 语言 类库 适配器
数据库 Ruby/Rails ActiveRecord MySQL, PostgreSQL, SQLite
队列 Python/Django Celery RabbitMQ, Beanstalkd, Redis
缓存 Ruby/Rails ActiveSupport::Cache Memory, filesystem, Memcached
开发人员有时会觉得在本地环境中使用轻量的后端服务具有很强的吸引力，而那些更重量级的健壮的后端服务应该使用在生产环境。例如，本地使用 SQLite 线上使用 PostgreSQL；又如本地缓存在进程内存中而线上存入 Memcached。

12-Factor 应用的开发人员应该反对在不同环境间使用不同的后端服务 ，即使适配器已经可以几乎消除使用上的差异。这是因为，不同的后端服务意味着会突然出现的不兼容，从而导致测试、预发布都正常的代码在线上出现问题。这些错误会给持续部署带来阻力。从应用程序的生命周期来看，消除这种阻力需要花费很大的代价。

与此同时，轻量的本地服务也不像以前那样引人注目。借助于Homebrew，apt-get等现代的打包系统，诸如Memcached、PostgreSQL、RabbitMQ 等后端服务的安装与运行也并不复杂。此外，使用类似 Chef 和 Puppet 的声明式配置工具，结合像 Vagrant 这样轻量的虚拟环境就可以使得开发人员的本地环境与线上环境无限接近。与同步环境和持续部署所带来的益处相比，安装这些系统显然是值得的。

不同后端服务的适配器仍然是## 不同后端服务的适配器仍然是有用的，因为它们可以使移植后端服务变得简单。但应用的所有部署，这其中包括开发、预发布以及线上环境，都应该使用同一个后端服务的相同版本。

XI. 日志

把日志当做事件流
日志 使得应用程序运行的动作变得透明。在基于服务器的环境中，日志通常被写在硬盘的一个文件里，但这只是一种输出格式。

日志应该是 事件流 的汇总，将所有运行中进程和后端服务的输出流按照时间顺序收集起来。尽管在回溯问题时可能需要看很多行，日志最原始的格式确实是一个事件一行。日志没有确定开始和结束，但随着应用在运行会持续的增加。

12-factor应用本身从不考虑存储自己的输出流。 不应该试图去写或者管理日志文件。相反，每一个运行的进程都会直接的标准输出（stdout）事件流。开发环境中，开发人员可以通过这些数据流，实时在终端看到应用的活动。

在预发布或线上部署中，每个进程的输出流由运行环境截获，并将其他输出流整理在一起，然后一并发送给一个或多个最终的处理程序，用于查看或是长期存档。这些存档路径对于应用来说不可见也不可配置，而是完全交给程序的运行环境管理。类似 Logplex 和 Fluentd 的开源工具可以达到这个目的。

这些事件流可以输出至文件，或者在终端实时观察。最重要的，输出流可以发送到 Splunk 这样的日志索引及分析系统，或 Hadoop/Hive 这样的通用数据存储系统。这些系统为查看应用的历史活动提供了强大而灵活的功能，包括：

找出过去一段时间特殊的事件。
图形化一个大规模的趋势，比如每分钟的请求量。
根据用户定义的条件实时触发警报，比如每分钟的报错超过某个警戒线。

XII. 管理进程

后台管理任务当作一次性进程运行
进程构成（process formation）是指用来处理应用的常规业务（比如处理 web 请求）的一组进程。与此不同，开发人员经常希望执行一些管理或维护应用的一次性任务，例如：

运行数据移植（Django 中的 manage.py migrate, Rails 中的 rake db:migrate）。
运行一个控制台（也被称为 REPL shell），来执行一些代码或是针对线上数据库做一些检查。大多数语言都通过解释器提供了一个 REPL 工具（python 或 perl） ，或是其他命令（Ruby 使用 irb, Rails 使用 rails console）。
运行一些提交到代码仓库的一次性脚本。
一次性管理进程应该和正常的 常驻进程 使用同样的环境。这些管理进程和任何其他的进程一样使用相同的 代码 和 配置 ，基于某个 发布版本 运行。后台管理代码应该随其他应用程序代码一起发布，从而避免同步问题。

所有进程类型应该使用同样的 依赖隔离 技术。例如，如果Ruby的web进程使用了命令 bundle exec thin start ，那么数据库移植应使用 bundle exec rake db:migrate 。同样的，如果一个 Python 程序使用了 Virtualenv，则需要在运行 Tornado Web 服务器和任何 manage.py 管理进程时引入 bin/python 。

12-factor 尤其青睐那些提供了 REPL shell 的语言，因为那会让运行一次性脚本变得简单。在本地部署中，开发人员直接在命令行使用 shell 命令调用一次性管理进程。在线上部署中，开发人员依旧可以使用ssh或是运行环境提供的其他机制来运行这样的进程。

转发自：https://12factor.net/zh_cn/

展开全文 >>

DevOps的三种方式

前言

这篇博客中提到的“三种方式“源自 《DevOps Handbook》 及《凤凰项目》（The Phoenix Project: A Novel About IT, DevOps, and Helping Your Business Win.），这三种方式描述了构成 DevOps 的理论框架、流程、实践及价值观和哲学。

感谢《Lean IT》的作者 Mike Orzen 为此文提供宝贵建议。

三种方式

下文将介绍三种模式及在该种模式指导下的 DevOps 实践。

第一种方式： 系统思考

第一种方式强调全局优化，而非局部改进。— 大到部门职能划分（例如研发部和运维部门），小到个人（开发和系统工程师）。

这种方式将关注点放在整个业务价值流上。换句话说，整个团队应该关注在从需求被定义到开发，再到运维这个过程，直到价值被以服务的形式交付给最终用户。

将这种方式带到实践中的产出便是永远不要将已知的缺陷传递到下游工作，永远不要为了局部优化影响了整体价值流交付，总是为了增加价值流动努力，永远追求对架构的深刻理解。

涉及到这种方式的实践有：

  • 所有环境和代码使用同一个仓库，将软件包纳入版本管理
  • 团队共同决定发布流程
  • 保持 DEV、TEST、PRODUCTION 环境的一致性
  • 自动化回归测试
  • 小步提交，每日部署；而不是一次部署大量变更
  • 更快、更频繁发布

第二种方式：经过放大的反馈回路

第二种方式是创建从开发过程下游至上游的反馈环。几乎所有的流程改进都是为了从时间上缩短和从覆盖面上放大反馈循环，从而可以不断地进行必要的改正。

第二种方式的产出是关注到价值流中所有涉及到的用户，包括价值流内部和外部的，缩短和放大反馈回路，并且可以随时定位到需要改进的地方。

涉及到这种方式的实践有：

  • 代码审查及配置变更检查
  • 有纪律的自动化测试，使许多同时的小型敏捷团队能够有效地工作
  • 尽早设置监控预警
  • 修复 bug 为团队最高优先级
  • 团队成员之间高度互相信任
  • 团队之间保持沟通和良好合作

第三种方式：持续做试验和学习的文化

第三种方式提倡持续做试验，承担风险、从失败中学习；通过反复实践来达到精通。

我们需要实验和冒着失败的风险，及时不断地尝试将我们置于一个危险的境地，我们要通过反复试错来掌握使我们远离危险的技能。

第三种方式的输出为为改善日常工作分配时间、奖励团队冒险精神，将错误人工引入系统以提高系统健壮性。

最具有代表性的就是 Netfilx 的 Chaos monkey ，Netflix 在他们的生产环境搭建一个服务用于定时随机关闭服务器，用以模拟服务器正常损坏或服务异常，他们的系统长期在这种环境下运行，“服务器故障”成为系统每日都要面临的问题，因此当服务器真的以外故障时不会对系统整体造成任何的影响。

译者后记

全局优化、快速反馈、鼓励失败。我们发现其实敏捷、精益、持续交付、DevOps中间有很多相似的东西。

参考资料: https://es.slideshare.net/SonatypeCorp/devops-connect-josh-corman-and-gene-kim-discuss-devopssec

http://itrevolution.com/the-three-ways-principles-underpinning-devops/

转发自：@duyidong

展开全文 >>

《那时花开》

作品：《那时花开》

字数：约 35000 字

体裁：中篇小说

关键字：校园青春

背景：小说记录了自己以在高中时期一群小伙伴的学习生活，作者：陈晓雷

袁河是高二上学期转到陆可凡他们班的。至于转班的原因却不得而知。不过众所周知的是，陆可凡他们班的语文老师是袁河的爸爸，所以就有人猜测这可能是他爸爸的注意，目的很简单，无非就是为了方便监督和管教儿子学习。那为什么到了高二才转班呢？答案也很简单，因为高二是承上启下的关键学期，既能延续高一时的学习状态，又能为高三做准备，所以这时转班最合适不过了。

转到陆可凡他们班上后，袁河发现了一个奇怪的现象。

比如一般课间休息的时候，同学们都会以固有的方式来放松自己。其中少数同学会走出教室，站在外面的走廊上，抬头仰望天空，认真盘算自己忧伤的心事。或者靠在旁边的栏杆上，低头看着地面，仔细回忆某天的快乐心情。而大多数同学则会三五成群地聚在一起，找一个大家都感兴趣的话题，然后各抒己见，开始谈论。 more >>

展开全文 >>

应用架构设计原则

软件系统架构设计原则就是把我们在各种场景下的架构设计进行抽选化提取公共特征形成过一定的方法论，这些方法论是经过严格推敲并具备移植性的，我们在设计系统时遵从这些设计规则可以为我们的体统提供更高的扩展性、稳定性。

抽象原则

各平台(含基础设施、中间件技术服务、各层业务服务等)需要通过合理地抽象，将内部信息、处理与扩展能力聚合成标准的服务于扩展接口，并通过统一的形式提供给使用者，屏蔽内部的实现与运行细节。

以下是一些符合抽象原则的架构规范或模式：
架构分层(layer)/级(tier)，层、级间提供标准服务与数据接口
根据业务模型，统一服务标准与数据标准
使用服务目录屏蔽服务位置等实现细节
使用“逻辑库”屏蔽数据库物理细节
通过SLA，标准化服务的质量水平
提供标准插件架构支持扩展
使用标准数据库特性，保持厂商无关性
使用逻辑的网络与系统名称
使用商品化硬件单元

共享原则

最大化重用数据、计算资源、业务组件等资产，防止数据、逻辑与技术实现不一致性带来的管理复杂性，避免重复建设成本与管理成本，通过安全机制保证共享资产的合法使用，通过业务分级保障共享资源效益最大化。
以下是一些符合共享原则的架构规范或模式：

  • 同一业务服务有唯一提供者
  • 同一技术服务有唯一提供者
  • 同一数据有唯一可信源
  • 控制技术多样性 (但需要同时防止厂商绑定)
  • 服务具备互操作性
  • 服务具备易用性
  • 统一的身份、访问控制与加解密机制
  • 为共享服务提供多租户能力 (Multi-tenancy)
  • 提供访问计量与控制能力
  • 提供业务分级能力，对不同级别的业务提供区分服务

自治原则

每一个组件（计算资源、业务组件、信息实体等）具备最大可能的自我完备性，可独立运行、监控、部署、配置与禁用，具备确定的SLA，并与其它组件之间以松散耦合的方式进行协作。当依赖的组件不存在或者无法正常提供服务时，能够以良好的方式降级，且在故障解除后自动恢复。
以下是一些符合自治原则的架构规范或模式：

  • 基于开-闭原则(OCP)设计组件
  • 应用无启动依赖
  • 最小化运行依赖集
  • 根据运行依赖关系合理安排组件物理colocation
  • 能够隔离依赖组件的故障
  • 异步调用 (提升异常流量的承载能力，简化故障隔离的实现)
  • 具备自我健康检查能力
  • 具备自我恢复能力
  • 无状态设计

冗余原则

各组件（计算资源、业务组件、数据等）都必须有充分、合理的冗余实例，保证单一组件实例失效不影响业务正常运行（多活/热备），或可以通过切换备份实例快速恢复（温备/冷备），不会丢失不可恢复的数据。针对不同类型的组件，需要明确定义冗余量与冗余类型。
以下是一些符合冗余原则的架构规范或模式：

  • 高可用水平扩展服务器集群（负载均衡、健康检查与自动切换）
  • 无单点设计 (含逻辑单点)
  • 采用“随机写”策略的数据库水平拆分
  • Failover数据库
  • N+1或N+x设计
  • “多活”数据中心
  • 数据复制
  • 灾难备份

分布原则

整个系统拆分成职责清晰、粒度恰当、便于管理的组件，各组件（计算资源、业务组件、数据等）可分布部署运行。组件的拆分与分布可以采取复制、根据功能垂直拆分、或根据用户与访问模式水平拆分等形式。
以下是一些符合分布原则的架构规范或模式：

  • 读写分离设计
  • 垂直分拆
  • 水平分拆
  • 柔性的分布事务

自动原则

系统设计了具备自监控、自管理、自适应与自优化能力，可以随着业务量与访问模式的变化、以及其它内、外部因素的改变，自动地对资源进行调度、调整服务策略，保障自身的稳定与服务的质量。
以下是一些符合自动原则的架构规范或模式：

  • 监控每一个服务的质量与资源的状态与报警
  • 从客户视角监控最终服务的质量
  • 统一、自动的错误报告、管理与响应
  • 提供完备的配置能力
  • 自动化系统安装
  • 自动化应用部署
  • 自动化资源分配
  • 可以mark up/mark down服务
  • 支持优雅降级
  • 自动拒绝超出SLA之外异常流量

展开全文 >>

消息收发中的中文乱码

背景：
A发消息给B系统，A、B应用的编码均为UTF-8，但是B收到的消息出现中文乱码。

A发送消息的方式：

1
new Message(TOPIC, TAG, null,          (messageContent.toString()).getBytes())

这里消息接受二进制byte数据，我们把消息string转换为byte的时候，默认使用了getBytes()，未指定编码方式，getBytes()方法的注释如下：

Encodes this {@code String} into a sequence of bytes using the
platform’s default charset, storing the result into a new byte array.

也就是会使用平台默认编码，查看StringCoding.encode方法中的Charset.defaultCharset().name()方法：

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
/**
  * Returns the default charset of this Java virtual machine.
  *
  * <p> The default charset is determined during virtual-machine startup and
  * typically depends upon the locale and charset of the underlying
  * operating system.
  *
  * @return  A charset object for the default charset
  *
  * @since 1.5
  */
 public static Charset defaultCharset() {
     if (defaultCharset == null) {
         synchronized (Charset.class) {
             String csn = AccessController.doPrivileged(
                 new GetPropertyAction("file.encoding"));
             Charset cs = lookup(csn);
             if (cs != null)
                 defaultCharset = cs;
             else
                 defaultCharset = forName("UTF-8");
         }
     }
     return defaultCharset;
 }

注释的很清楚了，返回JVM默认的字符编码，如果在jvm启动参数中指定了-Dfile.encoding 编码，则优先使用此编码，如果未指定，则使用UTF-8编码；

登录服务器查看启动参数，发现A应用进程中指定了-Dfile.encoding=GB18030

示意图如下：

总结：
在进行string与byte转换的时候，最好使用getBytes(String charsetName)方法，明确指定字符编码方式，最好编写一个编码转换的工具类，统一类型转换时的编码方式。

展开全文 >>

Linux phantomJs install course

背景：
我们在进行系统报告研发时，需要对报告结果进行定时邮件，所以需要把HTML内容自动转换为邮件内容，通常我们在发送邮件内容的时候内容是模板化的，模板基本不怎么改变，然而我们的报告却是由无数个子模块组成，这些子模块可以只有组合成为任意报告，每一个模块中的内容均为用户自定义，如果我们要实现通用化报告邮件化，那就需要把渲染后的报告转换为图片或者HTML格式，headless方案中常用的有phantomJS和Headless Chrome，phantomJS提供了截图等功能，所以称为我们的首选。

遇到的问题：

我们生产环境大部分机器操作系统为5u，默认的glibc版本最高到2.5。然而 PhantomJS官网中明确指出Linux 64-bit操作系统下，需要依赖GLIBCXX_3.4.9 和 GLIBC_2.7/GLIBC_2.9/GLIBC_2.10。

但是在我们生产环境中：

1
2
strings /lib64/libc.so.6 |grep GLIBC
strings /usr/lib64/libstdc++.so.6 |grep GLIBCXX

所以需要安装：GLIBCXX_3.4.9 GLIBC_2.7

一、安装phantoomjs

1. 安装node：

1
2
3
4
5
6
7
8
9
10
11
sudo wget  http://xxxxx/node-v6.11.2-linux-x64.tar.xz
sudo xz -d node-v6.11.2-linux-x64.tar.xz
sudo tar xvf node-v6.11.2-linux-x64.tar

sudo ln -s /home/admin/phantomjs/node-v6.11.2-linux-x64/bin/node /usr/local/bin/node
sudo ln -s /home/admin/phantomjs/node-v6.11.2-linux-x64/bin/npm /usr/local/bin/npm

sudo vi /etc/profile
PATH=$PATH:/home/admin/phantomjs/node-v6.11.2-linux-x64/bin

node -v

2. 安装npm：

1
curl -vvvL https://npmjs.com/install.sh >/dev/null

3. 安装phantomJS：

1
2
3
4
5
sudo wget http://xxxx/phantomjs-2.1.1-linux-x86_64.tar.bz2
sudo tar -jxvf phantomjs-2.1.1-linux-x86_64.tar.bz2
sudo ln -s /home/admin/phantomjs/phantomjs-2.1.1-linux-x86_64/bin/phantomjs /usr/local/bin/phantomjs

phantomjs --version


我们的系统中没有这些动态库，有联两种办法，第一自己安装这些版本，第二升级操作系统到7u，我们先尝试使用第一种方法。

二、安装GCC

因为部分版本的Glibc的安装需要高版本的GCC，默认的GCC版本为4.1.2，导致不能编译glibc的2.10以上版本，所以必须升级，gcc>=4.3.3。

1
2
3
4
cd  /home/admin/gcc/gcc-build
sudo yum install libstdc++-devel.i686
sudo yum install  libstdc++-devel.x86_64
sudo ../gcc-4.8.2/configure --prefix=/usr/local/gcc-4.8.2  --with-gmp=/usr/local/gmp-6.0.0 --with-mpfr=/usr/local/mpfr-3.1.2 --with-mpc=/usr/local/mpc-1.0.1  --with-java-home=/opt/taobao/java --disable-multilib  --disable-shared --enable-threads=posix --disable-checking  --enable-languages=all  --enable-static --enable-shared=libstdc++,libgcc_eh

或者：

1
2
3
4
5
6
7
8
9
10
11
12
sudo ../gcc-4.8.2/configure --prefix=/usr/local/gcc-4.8.2 --enable-threads=posix  --with-gmp=/usr/local/gmp-6.0.0 --with-mpfr=/usr/local/mpfr-3.1.2 --with-mpc=/usr/local/mpc-1.0.1  --mandir=/usr/share/man --infodir=/usr/share/info --enable-shared --disable-multilib --enable-checking=release --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-libgcj-multifile --enable-languages=c,c++,objc,obj-c++,java --disable-dssi --disable-plugin --with-java-home=/opt/taobao/java/jre --with-cpu=generic

sudo make
sudo make install 

#配置环境变量：
sudo vi /etc/profile
export PATH=$PATH:/usr/local/gcc-4.8.2
source /etc/profile

sudo rm /usr/bin/gcc    //删除旧的软连接  
sudo ln -s /usr/local/gcc-4.8.2/bin/gcc /usr/bin/gcc //使新版本建立软连接

安装完毕后，查看GCC版本：

1
2
3
4
5
6
7
8
$gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/local/gcc-4.8.2/libexec/gcc/x86_64-unknown-linux-gnu/4.8.2/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc-4.8.2/configure --prefix=/usr/local/gcc-4.8.2 --with-gmp=/usr/local/gmp-6.0.0 --with-mpfr=/usr/local/mpfr-3.1.2 --with-mpc=/usr/local/mpc-1.0.1 --with-java-home=/opt/taobao/java --disable-multilib --disable-shared --enable-threads=posix --disable-checking --enable-static --enable-shared=libstdc++
Thread model: posix
gcc version 4.8.2 (GCC)
出现错误1：
1
configure: error: cannot compute suffix of object files: cannot compile See `config.log' for more details

查看config.log，发现错误：

1
/home/admin/gcc/gcc-build/./gcc/cc1: error while loading shared libraries: libmpc.so.3: cannot open shared object file: No such file or directory

说明是环境变量设置未生效，检查环境变量&ldconfig相关设置。

出现错误2：
1
2
/usr/local/include/gnu/stubs.h:7:27: fatal error: gnu/stubs-32.h: No such file or directory
compilation terminated.

安装：
查看可用的版本：yum list available glibc-devel
sudo yum install glibc-devel
sudo yum install libstdc++-devel.i686

出现错误3：
1
2
3
/usr/lib/gcc/x86_64-redhat-linux/4.1.2/../../../../include/c++/4.1.2/iosfwd:44:28: error: bits/c++config.h: No such file or directory
/usr/lib/gcc/x86_64-redhat-linux/4.1.2/../../../../include/c++/4.1.2/iosfwd:45:29: error: bits/c++locale.h: No such file or directory
/usr/lib/gcc/x86_64-redhat-linux/4.1.2/../../../../include/c++/4.1.2/iosfwd:46:25: error: bits/c++io.h: No such file or directory

解决方案：

1
sudo yum install  libstdc++-devel.x86_64
出现错误4：
1
2
lib/libgmp.so: could not read symbols: File in wrong format collect2: error: ld returned 1 exit status
/home/admin/gcc/gcc-build/x86_64-unknown-linux-gnu/32/libjava/classpath/native/jni/java-math'

解决方案：

1
sudo ../gcc-4.8.2/configure --prefix=/usr/local/gcc-4.8.2 --enable-threads=posix --disable-checking --with-gmp=/usr/local/gmp-6.0.0 --with-mpfr=/usr/local/mpfr-3.1.2 --with-mpc=/usr/local/mpc-1.0.1 --enable-shared --enable-languages=all  --enable-libgomp --enable-lto --enable-tls --with-fpmath=sse --disable-multilib --build=x86_64-redhat-linux    --with-java-home=/opt/taobao/java
出现错误5：
1
Error: unrecognized symbol type "gnu_unique_object"

解决方案：移除 configure参数中的 gnu_unique_object 配置；

出现错误6：
1
configure: error: libXtst not found, required by java.awt.Robot

解决方案：移除 configure参数中的 java.awt 配置；

出现错误7：

libtool: compile: not configured to build any kind of library
解决方案：
sudo ../gcc-4.8.2/configure –prefix=/usr/local/gcc-4.8.2 –with-gmp=/usr/local/gmp-6.0.0 –with-mpfr=/usr/local/mpfr-3.1.2 –with-mpc=/usr/local/mpc-1.0.1 –with-java-home=/opt/taobao/java –disable-multilib –disable-shared –enable-threads=posix –disable-checking –enable-languages=all –enable-static –enable-shared=libstdc++,libgcc_eh

出现错误8：

cc1plus: error: unrecognized command line option “-Wno-narrowing”
解决方案：目前没有查询到好的解决方案；

出现错误9：

/usr/include/string.h:550:18: error: unknown type name ‘__locale_t’
解决方案：暂无

出现错误10：

/usr/lib64/libstdc++.so.6: undefined symbol: _ZNSt7num_getIcSt19istreambuf_iteratorIcSt11char_traitsIcEEE2idE, version GLIBCXX_3.4

三、安装GlibC

查看当前系统Glibc的版本：

1
strings /lib64/libc.so.6 |grep GLIBC

编译glibc：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
sudo mkdir glic
cd glic
sudo wget http://ftp.gnu.org/pub/gnu/glibc/glibc-2.7.tar.gz
sudo wget http://ftp.gnu.org/pub/gnu/glibc/glibc-2.9.tar.gz
//sudo wget http://ftp.gnu.org/pub/gnu/glibc/glibc-2.10.1.tar.gz
sudo wget http://ftp.gnu.org/pub/gnu/glibc/glibc-2.14.tar.gz

sudo tar zxvf glibc-2.7.tar.gz
sudo tar zxvf glibc-2.9.tar.gz
sudo tar zxvf glibc-2.10.1.tar.gz
sudo tar zxvf glibc-2.14.tar.gz

sudo mkdir glibc-build-2.7
sudo mkdir glibc-build-2.9
sudo mkdir glibc-build-2.10.1
sudo mkdir glibc-build-2.14

cd glibc-build-2.7

sudo ../glibc-2.7/configure

遇到错误：
configure: error: no acceptable C compiler found in $PATH
安装gcc套件(rpm -qa |grep gcc 可以看到目前的版本时4.1.2，注意此版本太老，导致不能编译glibc的2.10以上版本，所以必须升级，gcc>=4.3.3)：

遇到错误：

1
2
3
*** On GNU/Linux systems the GNU C Library should not be installed into
*** /usr/local since this might make your system totally unusable.
*** We strongly advise to use a different prefix.  For details read the FAQ.

INSTALL文件摘录如下：

configure' takes many options, but the only one that is usually mandatory is –prefix’. This option tells configure' where you want glibc installed. This defaults to /usr/local’, but the normal setting
to install as the standard system library is --prefix=/usr' for GNU/linux systems and –prefix=’ (an empty prefix) for GNU/Hurd
systems.

关于安装目录的选择:

1
--prefix=PREFIX

安装目录，默认为 /usr/local
Linux文件系统标准要求基本库必须位于 /lib 目录并且必须与根目录在同一个分区上，但是 /usr 可以在其他分区甚至是其他磁盘上。因此，如果指定 –prefix=/usr ，那么基本库部分将自动安装到 /lib 目录下，而非基本库部分则会自动安装到 /usr/lib 目录中。但是如果保持默认值或指定其他目录，那么所有组件都间被安装到PREFIX目录下。

1
2
3
sudo ../glibc-2.7/configure --prefix=/usr --disable-multi-arch
sudo ../glibc-2.9/configure --prefix=/usr --disable-multi-arch
sudo ../glibc-2.14/configure --prefix=/usr --disable-multi-arch

在每个build目录下，执行glibc的配置：

1
2
3
sudo ../glibc-2.7/configure --prefix=/usr --disable-multi-arch
sudo ../glibc-2.9/configure --prefix=/usr --disable-multi-arch
sudo ../glibc-2.10.1/configure --prefix=/usr --disable-multi-arch

分别进入每个build目录，执行命令(在 glibc-build-xx 目录下)：

1
sudo make all && make install

如果直接执行（sudo make install）出现错误提示：

1
2
3
4
5
make[2]: *** No rule to make target `/home/admin/glibc-build/dlfcn/libdl.so.2', needed by `/home/admin/glibc-build/elf/sprof'.  Stop.
make[2]: Leaving directory `/home/admin/glibc-2.7/elf'
make[1]: *** [elf/subdir_install] Error 2
make[1]: Leaving directory `/home/admin/glibc-2.7'
make: *** [install] Error 2

解决方案(先执行make all， 再执行 make install);

安装完毕后，出现提示：

1
2
Your new glibc installation seems to be ok.
make[1]: Leaving directory `/home/admin/glibc-2.7'
常见错误信息1：
1
2
/lib/modules/2.6.32-220.23.2.ali927.el5.x86_64/build/include/linux/swab.h:6:22: fatal error: asm/swab.h: No such file or directory
 #include <asm/swab.h>

解决办法：

1
sudo touch /lib/modules/2.6.32-220.23.2.ali927.el5.x86_64/build/include/asm-x86/swab.h

参考：https://bbs.archlinux.org/viewtopic.php?id=70488

常见错误信息2：

configure: error: assembler too old, .cfi_personality support missing
解决办法：google说gcc版本太老。

常见错误信息3：
1
/usr/bin/ld: cannot find -lgcc_eh

原因是： glibc在安装的时候，需要使用gcc_eh（–enable-shared），但是我们在安装gcc时，添加了–disable-shared，禁用了shared功能，所以导致此库找不到；
测试gcc_eh是否安装：sudo gcc -lgcc_eh –verbose

解决办法：

1
2
sudo find / -name libgcc.a
sudo cp libgcc.a libgcc_eh.a

参考：
http://www.linuxfromscratch.org/clfs/view/clfs-2.0/arm/cross-tools/glibc.html
https://gcc.gnu.org/ml/gcc-patches/2005-02/msg00532.html
http://lists.linuxfromscratch.org/pipermail/lfs-support/2012-December/044174.html

常见错误信息4：
1
Can't open configuration file /usr/etc/ld.so.conf: No such file or directory

参考：
http://www.math.ias.edu/~tarzadon/pages/posts/install-opam-on-springdalerhelcentossl-5.x-111.php

常见错误信息5：
1
/build/include/linux/capability.h:73: error: expected specifier-qualifier-list before ‘__le32’

解决方案：
参考：
https://github.com/spotify/linux/blob/master/include/linux/capability.h
sudo yum install openssl-devel gnutls-devel libcap-devel
查看版本：
strings /lib64/libc.so.6 |grep GLIBC

四、安装GLIBCXX

查看版本：strings /usr/lib64/libstdc++.so.6 |grep GLIBCXX
查看：ls -l /usr/lib64/libstdc++.so.6
lrwxrwxrwx 1 root root 18 Aug 14 2015 /usr/lib64/libstdc++.so.6 -> libstdc++.so.6.0.8

自己编译gcc的过程太繁琐，需要依赖非常多的文件，直接下载高版本下的文件进行替换：

1
2
3
4
5
6
7
8
9
sudo wget http://xxx/libstdc%2B%2B.so.6.0.13
sudo cp libstdc++.so.6.0.13 /usr/lib
sudo cp libstdc++.so.6.0.13 /usr/lib64

cd /usr/lib
sudo ln -sf libstdc++.so.6.0.13  libstdc++.so.6

cd /usr/lib64
sudo ln -sf libstdc++.so.6.0.13  libstdc++.so.6

再次执行

1
strings /usr/lib64/libstdc++.so.6 |grep GLIBCXX

发现需要的安装包已经安装完毕；

五、MAC下安装phantomJS：

下载文件到本地目录；
添加环境变量：

1
2
3
vi .bash_profile
export PATH=$PATH:/Users/xinyuan/soft/phantomjs-2.5.0-beta-macos/bin
source  .bash_profile

安装webp：

1
2
ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)" < /dev/null 2> /dev/null
brew install webp

建立软连：

1
ln -s  /usr/local/opt/webp/lib/libwebp.7.dylib /usr/local/opt/webp/lib/libwebp.6.dylib

查看版本：

1
2
phantomjs -v
2.5.0-development

六、总结：

整个OS的环境安装由于对linux底层不熟悉，参数配置也没有详细查看文档，导致安装过程出现了非常多的意外，之前使用的操作系统是5u，gcc版本为4.1.2，依赖的glibc、glibxx、gmp、mpfr、mpc库版本都比较低，但是phantomjs（JS截图）需要依赖其高版本库，为了升级响应的库，通过下载源码，make、install ，出现了不下于30个错误，每次解决一个错误后续流程中又出现了新的错误，费劲周折把所有依赖的库都装好后，运行phantomjs还是出错，怀疑是缺少了一些动态库； 后来还是通过升级操作系统，解决了此问题，升级操作系统完成docker化文件配置，总共才花费了不到一天时间。反思：遇到问题，首选需要评估一下解决此问题的最有效手段，而不是闷头上去搞，要看我们从中能得到什么，在linux操作系统上安装一坨软件并不能证明我们有什么能力，所以这件事情就不应该自己去尝试做，投入产出比是做事情非常重要的一个衡量手段。

七、参考链接：

http://blog.csdn.net/tsaiyong_ahnselina/article/details/21552485
http://siliconcali.com/2012/10/glibcxx_3-4-9-not-found-in-red-hatfedoracentos-linux/
http://blog.csdn.net/tengdazhang770960436/article/details/41348035
http://www.cnblogs.com/LitLeo/p/3534196.html
http://blog.csdn.net/wtfmonking/article/details/17577925
http://www.cnblogs.com/coolulu/p/4124803.html

展开全文 >>

tag:

    缺失模块。
    1、请确保node版本大于6.2
    2、在博客根目录（注意不是yilia根目录）执行以下命令：
    npm i hexo-generator-json-content --save

    3、在根目录_config.yml里添加配置： 

      jsonContent:
    meta: false
    pages: false
    posts:
      title: true
      date: true
      path: true
      text: false
      raw: false
      content: false
      slug: false
      updated: false
      comments: false
      link: false
      permalink: false
      excerpt: false
      categories: false
      tags: true

花名：心远，2011年加入淘宝，从事互联网行业的产品技术研发，为寻找梦想创过业；目前在阿里巴巴高可用架构团队，从事高可用稳定性保障相关工作，阿里云产品『应用高可用』研发负责人，chaos engine领域的专家。喜欢热情的工作，更喜欢百态的生活。