以太坊是一个开放的区块链平台，它允许任何人在平台上建立和使用通过区块链技术运行的去中心化应用。就像比特币一样，以太坊不受任何人控制，也不归任何人所有–它是一个开放源代码项目，有全球范围内很多人共同创建。

以太坊虚拟机

以太坊是可编程的区块链。它并不是给用户一系列预先设置好的操作，而是允许用户按照自己的意愿创建复杂的操作。

以太坊狭义上是指一系列定义去中心化应用平台的协议，它的核心是以太坊虚拟机（“EVM”），可以执行任意复杂算法的编码。在科学计算机术语中以太坊是“图灵完备的”。开发者能够使用现有的JavaScript和Python等语言为模型的其他友好语言创建出以太坊虚拟机上运行的应用。

以太坊如何工作

以太坊的基本单元是账户。以太坊区块链跟踪每个账户的状态，所有以太坊区块链上状态转化都是账户之间价值和信息的转移。账户分为两类：

• 外部账户（EOA)，由私人密码控制
• 合约账户，由他们的合约编码控制，智能由外部账户激活。
  对于大部分用户来说，两者基本区别在于外部账户是由人类用户控制–因为他们能够控制私钥，进而控制外部账户。而合约账户这是内部编码控制。
  只有外部账户发出指令时，合约账户才会执行相应的操作。所以合约账户不可能自发的执行诸如任意数据生成或应用程序调用等操作。
  和比特币一样，以太坊用户必须向网络支付少量的交易费用。这可以是以太坊区块链免受无关紧要或恶意的运算干扰，比如分布式拒绝服务(DDOS)攻击或无限循环。
  交易费由节点收集，节点使网络生效。

区块链，实质是由多方参与共同维护的一个持续增长的分布式数据库，也称为分布式共享账本，其核心在于通过分布式网路、时序不可篡改的密码学账本及分布式共识机制建立彼此之间的信任关系，利用由自动化脚本组成的智能合约来编程和操作数据，最终实现由信息互联向价值互联的进化。

区块链是一种与传统集中记账方式不同的记录技术。参与到区块链系统的节点，可能不属于同一组织、彼此无须信任；区块链数据由所有节点公共维护，每个参与维护的节点都能获得一份完整记录到拷贝。与传统的记账技术相比，其特点包括：维护一条不断增长的链，只可能添加记录，而发生过的记录不可篡改；无须集中控制而能达成共识，实现上尽量采用分布式；通过密码学的机制来确保交易无法抵赖和破坏，并尽量保护用户信息和记录的隐私性。

区块链的工作原理

所谓区块链，是由多个区块组成的链状数据结构及储存方式。每个区块分为区块头和区块体，区块头主要用来实现区块链接的前一去区块哈希值，而区块体主要包括交易账本。

以交易场景为例，区块链的工作原理如下：
1）客户端将发起一笔交易，经数字签名后广播给网络上的其他节点并等待确认；
2）网络中的节点对收到的数据记录信息进行校验，通过校验后，数据记录被记录到一个区块中；
3）全网所有的接收节点对区块进行共识算法，区块通过共识算法过程后正式纳入区块链中存储，全网节点均表示接受该区块。表示接受的方法，是将区块的随机哈希值视为最新的区块哈希值，新区块将提供永久和透明的交易记录并以该区块链为基础进行延长，实现资金转移。

区块链的技术特点

• 分布式结构
  区块链构建在分布式网络基础之上，账本并不是集中存放在某个服务器或数据中心，也不是由第三方权威机构来负责记录和管理，而是分散在网络中的每一个节点上，每一个节点都有一个该账本的副本，所有副本同步更新。
• 信任机制
  区块链技术通过数字原理和程序算法，使系统运作规则公开透明，实现交易双方在不需要借助第三方权威机构信用背书下通过达成共识，建立信任关系。
• 公开透明
  区块链对其三的节点可以做到开放、透明。任何人都可以加入区块链，也能查询区块链三的区块记录；同时所有用户看到的是同一个账本，能看到这个账本所发生和记录的每一笔交易。
• 时序不可篡改
  区块链采用带有时间戳的链式区块结构存储数据，具有极强的课追溯性和可验证性；同时由密钥学算法和共识机制保证了区块链的不可篡改性。

区块链层次模型

区块链技术的模型包括由自下而上的数据层、网络层、共识层、激励层、合约层和应用层，共有6层。
数据层、网络层、共识层是区块链的必要元素。

• 数据层
  最下层是”数据层“，它封装了底层数据区块的链式结构，以及相关的非对称公私钥数据加密技术和时间戳等技术，这是整个区块链技术中最底层的数据结构
• 网络层
  中间是网络层，包括P2P组网机制、数据传播机制和数据验证机制等。
• 共识层
  第三层是共识层，封装了网络节点的各类共识机制算法。
• 激励层
  第四层是激励层，它将经济因素集成到区块链技术体系中来，包括经济激励的发行机制和分配机制等，主要出现在公有链当中。
• 合约层
  第五层是合约层，它封装各类脚本、算法和智能合约
• 应用层
  第六层是应用层，它封装了区块链的各种应用场景和案例，未来的可编程金融和可编程社会也将搭建在应用层中。

区块链共识算法

区块链并不是某种特定技术，而是一种类似于NoSQL（非关系型数据库）这样的技术解决方案的统称。共识机制算法是区块链的核心技术，因为这决定了到底由谁来记账，而记账方式将会影响整个系统的安全性和可靠性。目前已经出现了十余种共识机制算法，其中比较知名的有PoW(Proof of Work,工作量证明)，PoS(Proof of Stake,权益证明)，DPoS(Delegate Proof of Stake ,股份授权证明)机制已经拜占庭将军容错共识等。当然，没有一种共识机制是完美无缺的，同时这也意味着没有共识机制是适合所有场景的。

• PoW(Proof of Work,工作量证明)
  就是挖矿，主要应用包括比特币和以太坊前三个阶段等。依赖机器进行数学运算来获取记账权，即通过与或运算，计算出一个满足规则的随机数，获得本次记账权，发出本轮需要记录的数据，全网其他节点验证后一起存储。优点是完全去中心化，节点自由进出；缺点是资源消耗相比其他共识机制高、可监管性弱，同时每次达成共识需要全网共同参与运算，性能效率比较低，达成共识的周期较长，因此不适合商业应用。
• PoS(Proof of Stake,权益证明)
  根据每个节点说占代币的比例和时间，等比例地降低难度，从而加快寻找随机数的速度，因此节点记账权的获得难度与节点持有的权益成反比，但它依然是基于哈希运算竞争获取记账权的方式。其优点是相对于PoW在一定程度减少了数学运算带来的资源消耗，性能也得到了相应的提升；缺点是还需要挖矿，本质上没有解决商业应用的痛点，可监管性也比较弱。
• DPoS(Delegate Proof of Stake ,股份授权证明)
  与PoW和PoS不同，DPoS不需要再挖矿了，而是类似余额董事会投票，持币者透出一定数量的节点，代理他们进行验证和记账，持股人拥有所持股份对应的表决权。优点是大幅缩小参与验证的记账节点的数量，可以达到秒级的共识验证，降低运行网络的成本和维护网络安全的费用，增强网络效能；缺点是整个共识机制还依赖于代币的，然而很多商业应用是不需要代币存在的。

区块链不一定是去中心化的

理想化的区块链系统，是由许许多多节点组成的点对点的网络结构，似乎即不需要中心化的硬件设备，也不需要任何管理它的机构。在很多文献中都提出区块链是去中心化的（Decentralized).即整个网络没有中心化的硬件或者管理机构，任意节点之间的权利和义务都是均等的，且任一节点的损坏或者失去不会影响整个系统的运作。

需要指出的是，区块链并不一定是去中心化的。实际上，软件系统的网络架构一般有3种模式：单中心、多中心、分布式，Decentralized只表明不是单中心模式的，它可能是多中心或弱中心的。

比特币起源于2008年全球金融危机期间中本聪撰写的论文《比特币：一种点对点的电子现金货币》

在这篇论文中，重点讨论了比特币系统，区块链被描述为用于记录比特币交易的账目历史。事实上，中本聪关于比特别的白皮书虽然整体思想是开创性的，单其中使用的技术工具，如P2P、分布式存储、非对称加密等早已存在，他提速的是一个集成性的、系统性的、可供实践的解决方案。

实际上这篇文章并没有明确提出区块链的定义和概念，甚至还没有“区块链”（Blockchain）这个词,只有“区块”（Block）和“链”（Chain）。但在论文中涉及了几个对区块链技术影响深远的观点：

• 点对点，去中心化的可靠交易
• 反欺诈
• 基于密码学原理的电子交易凭证管理
• 分布式的时间戳服务器
• 足够的安全能力支持系统

区块链演进趋势

区块链1.0阶段

我们可以把比特币理解为区块链技术的一个应用场景，也就是区块链1.0阶段。但是如果仅有比特币，区块链也只是一种数字货币，并不能达到今天的火爆程度，可以说比特币是当今区块链的“啥手级”应用，但是区块链可以做的事情远远超过比特币，很可能产生其它“杀手级”应用。

区块链2.0阶段

区块链2.0的重要标志就是被金融领域说接受并得到广泛应用形成的金融互联网，让价值交换变得便捷、直接、节省时间、节省成本。目前区块链2.0的实际场景中的应用，有两个重要因素：资产数字化（上链过程）与智能合约。

区块链3.0阶段

区块链3.0要把区块链的应用范围拓展到各行各业，支持广义的资产交互和登记，进入万物互联，设备民主的“区块链+”时代。

区块链起源

区块链技术起源于2008年中本聪《比特币：一种点对点电子现金系统》，区块链诞生自中本聪的比特币。

拜占庭将军问题

拜占庭帝国派10支军队进攻一敌人，这个敌人可抵御5支军队同时攻击，这10支军队不能集合单点突破，须分开同时攻击。问题是多个将军相互并不信任(存在叛徒)时，这种状态下要保证进攻一致，需要某种分布式协议来进行远程协调。如果每个将军向其他九个将军派出一名信使，总计90次传输，每个将军会收到9条信息，可能每一封都附着不同的进攻时间。此外，部分叛徒会故意答应超过一个的攻击时间，所以他们将重新广播超过一条的信息链。这个系统变成不可靠信息和攻击时间矛盾的混合体。

• 解决思路
  拜占庭将军故事的最后，数学家设计了一套算法，让将军们在接到上一位将军的信息之后，加上自己的签名再转给自己之外的其他将军，这样的信息模块就形成了区块链。

区块链引言

• 拜占庭将军问题延伸至互联网生活，即：在互联网大背景下，当需要与不熟悉的对手进行价值交换活动时，人们如何才能防止不会被其中的恶意破坏欺骗、迷惑从而错误决策。
• 再把该问题抽象化，理解为：在缺少可信任中央节点和可信任通道情况下，分布在网络中的各节点应如何达成共识。
• 这一对拜占庭将军问题的解决方案，可以推广到任何核心问题是在分布式网络上缺乏信任的领域。

区块链的目的：用于验证其信息的有效性（防伪）

什么是区块链

区块链是比特币的底层技术，像一个数据库账本，记载所有的交易记录。

在一个40人以上的微信群里组局聚餐，如何统计人数？一种方式是大家纷纷发言，有个人来统计；另一种方式是大家接龙，每个人在上一个人的发言后面累加一个号并加上自己的名字，最后就能记录全部的报名人员和人数–》区块链。

区块链中的“区块”指的是信息块，这个信息块内包含有一个特殊的信息就是时间戳。含有时间戳的信息块彼此互联，形成的信息块链条被称为“区块链”。

• 一是数据结构，接龙发帖只记录“上一贴加1”这个简单计算，而区块链里记账的信息会复杂的多，每一个区块记录了上一个区块、时间戳、从上一个区块到这个区块之间发生的所有交易记录。
• 二是博弈机制，用来解决链式结构万一遇到分叉了怎么办？在微信组局的情景里，如果有两人同时发帖、或者有人因为网络延迟导致没有在最新的帖子后面跟帖导致重号怎么办？很自然的办法就是，哪个跟帖跟的多，以哪个为准；出现重复的人乖乖到较多的哪个跟帖后面写上自己的跟帖。区块链里也基本一样，以一定时间为限，哪条分叉较长就以哪个为准进行记录，较短的分叉上记录的交易作废，推迟到下一个时间段里记的账里。
• 三是非对称加密技术，用来解决陌生人之间的信任问题。这是跟微信组局最大的不同，微信的认证帮助用户做了过滤，群里的都是熟人/可信的人。在区块链里利用哈希、PKI公钥体系为每个人制作了一个唯一密码生成的唯一地址，功能类似于国内网银用的“U盾”，凡是用这个”U盾”接入区块链的，就可以进行交易，别人能识别你的身份，但是无法伪装成你。这样解决了信任体系的问题。

  定义

  区块链是一个分布式账本，一种通过去中心化、去信任的方式集体维护一个可靠数据库的技术方案。

  从数据的角度来看

  区块链是一种几乎不可能被更改的分布式数据库。这里的“分布式”不仅体现为数据的分布式存储，也体现为数据的分布式记录（即由系统参与者共同维护）。

  从技术的角度来看

  区块链并不是一种单一的技术，而是多种技术整合的结果。这些技术以新的结构组合在一起，形成了一种新的数据记录、存储和表达的方式。

  特征

  开放，共识

  任何人都可以参与到区块链网络，每一台设备都能作为一个节点，每个节点都允许后的一份完整的数据库拷贝。节点间基于一同共识机制，通过竞争计算共同维护整个区块链。任一节点失效，其他节点仍能正常工作。

  去中心，去信任

  区块链由众多节点共同组成一个端到端的网络，不存在中心化的设备和管理机构。节点之间数据交换通过数字签名技术进行验证，无需互相信任，只要按照系统既定的规则进行，节点之间不能也无法欺骗其它节点。

  交易透明，双方匿名

  区块链的运行规则是公开透明的，所有的数据信息也是公开的，因此每一笔交易都对所有节点可见。由于节点与节点之间是去信任的，因此节点之间无需公开身份，每个参与的节点都是匿名的。

  不可篡改，可追溯

  单个甚至多个节点对数据库的修改无法影响其他节点的数据库，除非能控制整个网络中超过51%的节点同时修改，这几乎不可能发生。区块链中的每一笔交易都通过密码学方法与相邻两个区块串联，因此可以追溯到任何一笔交易的前世今生。

  分类

  公有链

  无官方组织及管理机构，无中心服务器，参与的节点按照系统规则自由接入网络、不受控制，节点间基于共识机制开展工作。

  私有链

  建立在某个企业内部，系统的运作规则根据企业要求进行设定，修改甚至是读取权限仅限于少数节点，同时仍然保留着区块链的真实性和部分去中心化的特性。

  联盟链

  由若干机构联合发起，介于公有链和私有链之间，兼具部分去中心化的特性。

API与用户的通信协议，总是使用HTTPs协议。

域名

应该尽量将API部署在专用域名之下。

https://api.example.com

如果确定API很简单，不会有进一步扩展，可以考虑放在主域名下。

https://example.com/api/

版本（Versioning）

应该将API的版本号放入URL。

https://api.example.com/v1/

另一种做法是，将版本号放在HTTP头信息中，但不如放入URL方便和直观。Github采用这种做法。

路径（Endpoint）

路径又称”终结点”（endpoint），表示API的具体网址。
在RESTful架构中，每个网址代表一种资源（resource），所以网址中不能有动词，只能有名词，而且所用的名词往往与数据库的表格名对应。一般来说，数据库中的表都是同种记录的”集合”（collection），所以API中的名词也应该使用复数。
举例来说，有一个API提供用户（user）的信息，则它的路径应该设计成下面这样。

https://api.example.com/v1/users

HTTP方法

对于资源的具体操作类型，由HTTP方法表示。
常用的HTTP方法有下面五个（括号里是对应的SQL命令）。

• GET（SELECT）：从服务器取出资源（一项或多项）。
• POST（CREATE）：在服务器新建一个资源。
• PUT（UPDATE）：在服务器更新资源（客户端提供改变后的完整资源）。
• PATCH（UPDATE）：在服务器更新资源（客户端提供改变的属性）。
• DELETE（DELETE）：从服务器删除资源。

---

还有两个不常用的HTTP方法。

• HEAD：获取资源的元数据。
• OPTIONS：获取信息，关于资源的哪些属性是客户端可以改变的。

下面是一些例子。

• GET /users：列出所有用户
• POST /users：新建一个用户
• GET /users/ID：获取某个指定用户的信息
• PUT /users/ID：更新某个指定用户的信息（提供该用户的全部信息）
• PATCH /users/ID：更新某个指定用户的信息（提供该用户的部分信息）
• DELETE /users/ID：删除某个用户
• GET /users/ID/address：列出某个指定用户的所有地址
• DELETE /users/ID/address/ID：删除某个指定用户的指定地址

过滤信息（Filtering）

如果记录数量很多，服务器不可能都将它们返回给用户。API应该提供参数，过滤返回结果。
下面是一些常见的参数。

• ?limit=10：指定返回记录的数量
• ?offset=10：指定返回记录的开始位置。
• ?page=2&per_page=100：指定第几页，以及每页的记录数。
• ?sortby=name&order=asc：指定返回结果按照哪个属性排序，以及排序顺序。
• ?animal_type_id=1：指定筛选条件

参数的设计允许存在冗余，即允许API路径和URL参数偶尔有重复。比如，GET /users/ID/address 与 GET /address?user_id=ID 的含义是相同的。

状态码（Status Codes）

服务器向用户返回的状态码和提示信息，常见的有以下一些（方括号中是该状态码对应的HTTP动词）。

• 200 OK - [GET]：服务器成功返回用户请求的数据，该操作是幂等的（Idempotent）。
• 201 CREATED - [POST/PUT]：用户新建或修改数据成功。
• 202 Accepted - [* ]：表示一个请求已经进入后台排队（异步任务）
• 204 NO CONTENT - [DELETE/PATCH]：服务器成功处理了请求,但不需要返回任何实体内容。
• 400 INVALID REQUEST - [POST/PUT/PATCH]：用户发出的请求有错误，服务器没有进行新建或修改数据的操作，该操作是幂等的。
• 401 Unauthorized - [* ]：表示用户没有权限（令牌、用户名、密码错误）。
• 403 Forbidden - [* ] 表示用户得到授权（与401错误相对），但是访问是被禁止的。
• 404 NOT FOUND - [* ]：用户发出的请求针对的是不存在的记录，服务器没有进行操作，该操作是幂等的。
• 406 Not Acceptable - [GET]：用户请求的格式不可得（比如用户请求JSON格式，但是只有XML格式）。
• 410 Gone -[GET]：用户请求的资源被永久删除，且不会再得到的。
• 422 Unprocesable entity - [POST/PUT/PATCH] 当创建一个对象时，发生一个验证错误。
• 500 INTERNAL SERVER ERROR - [* ]：服务器发生错误，用户将无法判断发出的请求是否成功。

状态码的完全列表参见这里。

错误处理（Error handling）

如果状态码是4xx，就应该向用户返回出错信息。一般来说，返回的信息中将error作为键名，出错信息作为键值即可。

1
2
3

{
  error: "Invalid API key"
}

返回结果

针对不同操作，服务器向用户返回的结果应该符合以下规范。

• GET /collection：返回资源对象的列表（数组）
• GET /collection/resource：返回单个资源对象
• POST /collection：返回新生成的资源对象
• PUT /collection/resource：返回完整的资源对象
• PATCH /collection/resource：返回一个空文档
• DELETE /collection/resource：返回一个空文档

Hypermedia API

RESTful API最好做到Hypermedia，即返回结果中提供链接，连向其他API方法，使得用户不查文档，也知道下一步应该做什么。
比如，当用户向api.example.com的根目录发出请求，会得到这样一个文档。

1
2
3
4
5
6
7
8

{
  "link": {
    "rel":   "collection https://www.example.com/users",
    "href":  "https://api.example.com/users",
    "title": "List of users",
    "type":  "application/vnd.yourformat+json"
  }
}

上面代码表示，文档中有一个link属性，用户读取这个属性就知道下一步该调用什么API了。rel表示这个API与当前网址的关系（collection关系，并给出该collection的网址），href表示API的路径，title表示API的标题，type表示返回类型。
Hypermedia API的设计被称为HATEOAS。Github的API就是这种设计，访问api.github.com会得到一个所有可用API的网址列表。

1
2
3
4
5

{
  "current_user_url": "https://api.github.com/user",
  "authorizations_url": "https://api.github.com/authorizations",
  // ...
}

从上面可以看到，如果想获取当前用户的信息，应该去访问api.github.com/user，然后就得到了下面结果。

1
2
3
4

{
  "message": "Requires authentication",
  "documentation_url": "https://developer.github.com/v3"
}

上面代码表示，服务器给出了提示信息，以及文档的网址。

Git是一款免费、开源的分布式版本控制系统，可以有效、高速的处理从很小到非常大的项目版本管理

git和svn的差异

git和svn最大的差异在于git是分布式的管理方式而svn是集中式的管理方式。

集中式管理

• 集中式管理的工作流程图：

  

  集中式管理的工作流程图

集中式代码管理的核心是服务器，所有开发者在开始新一天的工作之前必须从服务器获取代码，然后开发，最后解决冲突，提交。所有的版本信息都放在服务器上。如果脱离了服务器，开发者基本上是不可以工作。下面举例说明：

开始新一天的工作：

1. 从服务器下载项目组最新代码。
2. 进入自己的分支，进行工作，每隔1个小时向服务器自己的分支提交一次代码（很多人都有这个习惯。因为有时候自己对代码改来改去，最后又想还原到前一个小时的版本，或者看看前一个小时自己修改了哪些代码，就需要这样做了）。
3. 下班时间快到了，把自己的分支合并到服务器主分支上，一天的工作完成，并反映给服务器。
   这就是经典的svn工作流程，从流程上看，有不少缺点，但也有优点。

• 缺点：

1. 服务器压力太大，数据库容量暴增。
2. 如果不能连接到服务器上，基本上不可以工作，看上面第二步，如果服务器不能连接上，就不能提交，还原，对比等等。
3. 不适合开源开发（开发人数非常非常多，但是Google app engine就是用svn的）。但是一般集中式管理的有非常明确的权限管理机制（例如分支访问限制），可以实现分层管理，从而很好的解决开发人数众多的问题。

• 优点：

1. 管理方便，逻辑明确，符合一般人思维习惯。
2. 易于管理，集中式服务器更能保证安全性。
3. 代码一致性非常高。
4. 适合开发人数不多的项目开发。
5. 大部分软件配置管理的大学教材都是使用svn 和vss。

分布式管理

• 分布式管理的工作流程图：

  

  分布式管理的工作流程图

分布式和集中式的最大区别在于开发者可以在本地提交。每个开发者机器上都有一个服务器的数据库。
上图就是经典的git开发过程。步骤如下：

• 一般开发者的角度：

1. 从服务器上克隆数据库（包括代码和版本信息）到单机上。
2. 在自己的机器上创建分支，修改代码。
3. 在单机上自己创建的分支上提交代码。
4. 在单机上合并分支。
5. 新建一个分支，把服务器上最新版的代码fetch下来，然后跟自己的主分支合并。
6. 生成补丁（patch），把补丁发送给主开发者。
7. 看主开发者的反馈，如果主开发者发现两个一般开发者之间有冲突（他们之间可以合作解决的冲突），就会要求他们先解决冲突，然后再由其中一个人提交。如果主开发者可以自己解决，或者没有冲突，就通过。
8. 一般开发者之间解决冲突的方法，开发者之间可以使用pull命令解决冲突，解决完冲突之后再向主开发者提交补丁。

• 主开发者的角度（假设主开发者不用开发代码）：

1. 查看邮件或者通过其它方式查看一般开发者的提交状态。
2. 打上补丁，解决冲突（可以自己解决，也可以要求开发者之间解决以后再重新提交，如果是开源项目，还要决定哪些补丁可用，哪些不用）。
3. 向公共服务器提交结果，然后通知所有开发人员。

• 优点：

1. 适合分布式开发，强调个体。
2. 公共服务器压力和数据量都不会太大。
3. 速度快、灵活。
4. 任意两个开发者之间可以很容易的解决冲突。

• 缺点：

1. 资料少（起码中文资料很少）。
2. 学习周期相对而言比较长。
3. 不符合常规思维。
4. 代码保密性差，一旦开发者把整个库克隆下来就可以完全公开所有代码和版本信息。

git常用命令介绍

Docker 是一个开源项目，诞生于 2013 年初，最初是 dotCloud 公司内部的一个业余项目。它基于 Google 公司推出的 Go 语言实现。 它基于Linux容器技术（LXC），Namespace(命名空间)，Cgroup(控制组)，UnionFS（联合文件系统）等技术。项目后来加入了 Linux 基金会，遵从了 Apache 2.0 协议，项目代码在 GitHub 上进行维护。

namespace（命名空间）： 命名空间是 Linux 内核一个强大的特性。每个容器都有自己单独的名字空间，运行在其中的应用都像是在独立的操作系统中运行一样。名字空间保证了容器之间彼此互不影响。docker实际上一个进程容器，它通过namespace实现了进程和进程所使用的资源的隔离。使不同的进程之间彼此不可见。我们可以把Docker容器想像成进程＋操作系统除内核之外的一套软件。

cgroup（控制组）： 是 Linux 内核的一个特性，主要用来对共享资源进行隔离、限制、审计等。只有能控制分配到容器的资源，才能避免当多个容器同时运行时的对系统资源的竞争。控制组技术最早是由 Google 的程序员 2006 年起提出，Linux 内核自 2.6.24 开始支持。控制组可以提供对容器的内存、CPU、磁盘 IO 等资源的限制和审计管理。

UnionFS（联合文件系统）： Union文件系统（UnionFS）是一种分层、轻量级并且高性能的文件系统，它支持对 文件系统的修改作为一次提交来一层层的叠加，同时可以将不同目录挂载到同一个虚拟文件系统下(unite several directories into a single virtual filesystem)。Union 文件系统是 Docker 镜像的基础。镜像可以通过分层来进行继承，基于基础镜像（没有父镜像），可以制作各种具体的应用镜像。另外，不同 Docker 容器就可以共享一些基础的文件系统层，同时再加上自己独有的改动层，大大提高了存储的效率。Docker 中使用的 AUFS（AnotherUnionFS）就是一种 Union FS。 AUFS 支持为每一个成员目录（类似 Git 的分支）设定只读（readonly）、读写（readwrite）和写出（whiteout-able）权限, 同时 AUFS 里有一个类似分层的概念, 对只读权限的分支可以逻辑上进行增量地修改(不影响只读部分的)。

快速理解Docker

拿现实世界中货物的运输作类比, 为了解决各种型号规格尺寸的货物在各种运输工具上进行运输的问题,我们发明了集装箱

集装箱

docker

docker

每个container拥有自己独立的各种命名空间(亦即资源)包括:PID 进程, MNT 文件系统, NET 网络, IPC , UTS 主机名 等

为什么要使用Docker

作为一种新兴的虚拟化方式，Docker 跟传统的虚拟化方式相比具有众多的优势。

首先，Docker 容器的启动可以在秒级实现，这相比传统的虚拟机方式要快得多。 其次，Docker 对系统资源的利用率很高，一台主机上可以同时运行数千个 Docker 容器。

容器除了运行其中应用外，基本不消耗额外的系统资源，使得应用的性能很高，同时系统的开销尽量小。传统虚拟机方式运行 10 个不同的应用就要起 10 个虚拟机，而Docker 只需要启动 10 个隔离的应用即可。

具体说来，Docker 在如下几个方面具有较大的优势。

• 更快速的交付和部署
  对开发和运维（devop）人员来说，最希望的就是一次创建或配置，可以在任意地方正常运行。
  开发者可以使用一个标准的镜像来构建一套开发容器，开发完成之后，运维人员可以直接使用这个容器来部署代码。 Docker 可以快速创建容器，快速迭代应用程序，并让整个过程全程可见，使团队中的其他成员更容易理解应用程序是如何创建和工作的。 Docker 容器很轻很快！容器的启动时间是秒级的，大量地节约开发、测试、部署的时间。
• 更高效的虚拟化
  Docker 容器的运行不需要额外的 hypervisor 支持，它是内核级的虚拟化，因此可以实现更高的性能和效率。
• 更轻松的迁移和扩展
  Docker 容器几乎可以在任意的平台上运行，包括物理机、虚拟机、公有云、私有云、个人电脑、服务器等。 这种兼容性可以让用户把一个应用程序从一个平台直接迁移到另外一个。
• 更简单的管理
  使用 Docker，只需要小小的修改，就可以替代以往大量的更新工作。所有的修改都以增量的方式被分发和更新，从而实现自动化并且高效的管理。

Docker基本概念

• 镜像（Image）
  Docker的镜像概念类似于虚拟机里的镜像，是一个只读的模板，一个独立的文件系统，包括运行容器所需的数据，可以用来创建新的容器。镜像可以基于Dockerfile构建，Dockerfile是一个描述文件，里面包含若干条命令，每条命令都会对基础文件系统创建新的层次结构。用户可以通过编写Dockerfile创建新的镜像，也可以直接从类似github的Docker Hub上下载镜像使用。
• 容器（Container）
  Docker容器是由Docker镜像创建的运行实例。Docker容器类似虚拟机，可以支持的操作包括启动，停止，删除等。每个容器间是相互隔离的，但隔离的效果比不上虚拟机。容器中会运行特定的应用，包含特定应用的代码及所需的依赖文件。

在Docker容器中，每个容器之间的隔离使用Linux的 CGroups 和 Namespaces技术实现的。其中 CGroups 对CPU，内存，磁盘等资源的访问限制，Namespaces 提供了环境的隔离。

• 仓库（Repository）
  Docker仓库相当于一个 github 上的代码库。

Docker 仓库是用来包含镜像的位置，Docker提供一个注册服务器（Registry）来保存多个仓库，每个仓库又可以包含多个具备不同tag的镜像。Docker运行中使用的默认仓库是 Docker Hub 公共仓库。

仓库支持的操作类似 git，创建了新的镜像后，我们可以 push 提交到仓库，也可以从指定仓库 pull 拉取镜像到本地。

TCC事务机制简介

关于TCC（Try-Confirm-Cancel）的概念，最早是由Pat Helland于2007年发表的一篇名为《Life beyond Distributed Transactions:an Apostate’s Opinion》的论文提出。在该论文中，TCC还是以Tentative-Confirmation-Cancellation作为名称；正式以Try-Confirm-Cancel作为名称的，可能是Atomikos（Gregor Hohpe所著书籍《Enterprise Integration Patterns》中收录了关于TCC的介绍，提到了Atomikos的Try-Confirm-Cancel，并认为二者是相似的概念）。

国内最早关于TCC的报道，应该是InfoQ上对阿里程立博士的一篇采访。经过程博士的这一次传道之后，TCC在国内逐渐被大家广为了解并接受。相应的实现方案和开源框架也先后被发布出来。

TCC事务机制相对于传统事务机制（X/Open XA），其特征在于它不依赖资源管理器(RM)对XA的支持，而是通过对（由业务系统提供的）业务逻辑的调度来实现分布式事务。对于业务系统中一个特定的业务逻辑S，其对外提供服务时，必须接受一些不确定性，即对业务逻辑执行的一次调用仅是一个临时性操作，调用它的消费方服务M保留了后续的取消权。如果M认为全局事务应该rollback，它会要求取消之前的临时性操作，这就对应S的一个取消操作。而当M认为全局事务应该commit时，它会放弃之前临时性操作的取消权，这对应S的一个确认操作。 每一个初步操作，最终都会被确认或取消。因此，针对一个具体的业务服务，TCC事务机制需要业务系统提供三段业务逻辑：初步操作Try、确认操作Confirm、取消操作Cancel。

1. 初步操作（Try）
TCC事务机制中的业务逻辑（Try），从执行阶段来看，与传统事务机制中业务逻辑相同。但从业务角度来看，是不一样的。TCC机制中的Try仅是一个初步操作，它和后续的次确认一起才能真正构成一个完整的业务逻辑。因此，可以认为[传统事务机制]的业务逻辑 = [TCC事务机制]的初步操作（Try） + [TCC事务机制]的确认逻辑（Confirm）。TCC机制将传统事务机制中的业务逻辑一分为二，拆分后保留的部分即为初步操作（Try）；而分离出的部分即为确认操作（Confirm），被延迟到事务提交阶段执行。
TCC事务机制以初步操作（Try）为中心，确认操作（Confirm）和取消操作（Cancel）都是围绕初步操作（Try）而展开。因此，Try阶段中的操作，其保障性是最好的，即使失败，仍然有取消操作（Cancel）可以将其不良影响进行回撤。

2. 确认操作（Confirm）
确认操作（Confirm）是对初步操作（Try）的一个补充。当TCC事务管理器认为全局事务可以正确提交时，就会逐个执行初步操作（Try）指定的确认操作（Confirm），将初步操作（Try）未完成的事项最终完成。

3. 取消操作（Cancel）
取消操作（Cancel）是对初步操作（Try）的一个回撤。当TCC事务管理器认为全局事务不能正确提交时，就会逐个执行初步操作（Try）指定的取消操作（Cancel），将初步操作（Try）已完成的事项全部撤回。

支付宝运营架构中柔性事务

• 柔性事务：业务活动

  

  柔性事务：业务活动

• 柔性事务：业务活动举例

  

  柔性事务：业务活动举例

• 柔性事务：TCC型业务服务

  

  柔性事务：TCC型业务服务

• 柔性事务：TCC服务事务协调模式

  

  柔性事务：TCC服务事务协调模式

  可以看出，柔性事务（遵循BASE理论）是指相对于ACID刚性事务而言的。

支付宝所说的柔性事务分为：两阶段型、补偿型、异步确保型、最大努力通知型几种。由于支付宝整个架构是SOA架构，因此传统单机环境下数据库的ACID事务满足了分布式环境下的业务需要，以上几种事务类似就是针对分布式环境下业务需要设定的。其中：
1、两阶段型：就是分布式事务两阶段提交，对应技术上的XA、JTA/JTS。这是分布式环境下事务处理的典型模式。
2、补偿型：TCC型事务（Try/Confirm/Cancel）可以归为补偿型。补偿型的例子，在一个长事务（long-running）中，一个由两台服务器一起参与的事务，服务器A发起事务，服务器B参与事务，B的事务需要人工参与，所以处理时间可能很长。如果按照ACID的原则，要保持事务的隔离性、一致性，服务器A中发起的事务中使用到的事务资源将会被锁定，不允许其他应用访问到事务过程中的中间结果，直到整个事务被提交或者回滚。这就造成事务A中的资源被长时间锁定，系统的可用性将不可接受。WS-BusinessActivity提供了一种基于补偿的long-running的事务处理模型。还是上面的例子，服务器A的事务如果执行顺利，那么事务A就先行提交，如果事务B也执行顺利，则事务B也提交，整个事务就算完成。但是如果事务B执行失败，事务B本身回滚，这时事务A已经被提交，所以需要执行一个补偿操作，将已经提交的事务A执行的操作作反操作，恢复到未执行前事务A的状态。这样的SAGA事务模型，是牺牲了一定的隔离性和一致性的，但是提高了long-running事务的可用性。例子来源：OASIS的WS-BusinessActivity文档
3、异步确保型将一些同步阻塞的事务操作变为异步的操作，避免对数据库事务的争用，典型例子是热点账户异步记账、批量记账的处理。
4、最大努力型PPT中提到的例子交易的消息通知（例如商户交易结果通知重试、补单重试）

参考

大规模SOA系统中的分布事务处事
支付宝架构与技术

MongoDB 是由C++语言编写的，是一个基于分布式文件存储的开源数据库系统。
在高负载的情况下，添加更多的节点，可以保证服务器性能。
MongoDB 旨在为WEB应用提供可扩展的高性能数据存储解决方案。
MongoDB 将数据存储为一个文档，数据结构由键值(key=>value)对组成。MongoDB 文档类似于 JSON 对象。字段值可以包含其他文档，数组及文档数组。

MongoDB特点

1. 支持特别查询
   在MongoDB中，可以通过字段，范围查询进行搜索，并且还支持正则表达式搜索。
2. 索引
   可以索引文档中的任何字段。
3. 复制
   MongoDB支持主从复制。主机可以执行读写操作，从机从主机复制数据，只能用于读取或备份(不写入)
4. 复制数据
   MongoDB可以在多台服务器上运行。 复制数据以保持系统正常运行，并在硬件故障的情况下保持其运行状态。
5. 负载均衡
   由于数据放在碎片中，因此具有自动负载平衡配置。
6. 支持映射缩减和聚合工具
7. 使用JavaScript而不是Procedure
8. 它是一个用C++编写的无模式数据库
9. 提供高性能
10. 轻松存储任何大小的文件，而不会使您的堆栈复杂化
11. 在故障的情况下易于管理
12. 它还支持：

• 具有动态模式的JSON数据模型
• 自动分片用于水平可扩展性
• 内置复制高可用性

MongoDB优点

• MongoDB 的架构较少。它是一个文档数据库，它的一个集合持有不同的文档。
• 从一个到另一个的文档的数量，内容和大小可能有差异。
• MongoDB 中单个对象的结构很清淅。
• MongoDB 中没有复杂的连接。
• MongoDB 提供深度查询的功能，因为它支持对文档的强大的动态查询。
• MongoDB 很容易扩展。
• 它使用内部存储器来存储工作集，这是其快速访问的原因。

MongoDB的独特功能

• 使用方便
• 重量轻/轻量级
• 比RDBMS快得多

应该使用MongoDB在哪些场景

• 大而复杂的数据
• 移动和社会基础设施数据
• 内容管理和交付
• 用户数据管理
• 数据中心

MongoDB和RDBMS的性能分析

• 在关系数据库(RDBMS)中，表用作存储元素，而在 MongoDB 中使用的是集合。
• 在RDBMS中有多个模式，在每个模式中，可创建用于存储数据的表，而 MongoDB 是面向文档的数据库，数据是以类似JSON格式的BSON格式编写的存储的。
• MongoDB几乎比传统数据库系统快100倍。

MongoDB 应用案例

下面列举一些公司MongoDB的实际应用：

• Craiglist上使用MongoDB的存档数十亿条记录。
• FourSquare，基于位置的社交网站，在Amazon EC2的服务器上使用MongoDB分享数据。
• Shutterfly，以互联网为基础的社会和个人出版服务，使用MongoDB的各种持久性数据存储的要求。
• bit.ly, 一个基于Web的网址缩短服务，使用MongoDB的存储自己的数据。
• spike.com，一个MTV网络的联营公司， spike.com使用MongoDB的。
• Intuit公司，一个为小企业和个人的软件和服务提供商，为小型企业使用MongoDB的跟踪用户的数据。
• sourceforge.net，资源网站查找，创建和发布开源软件免费，使用MongoDB的后端存储。
• etsy.com ，一个购买和出售手工制作物品网站，使用MongoDB。
• 纽约时报，领先的在线新闻门户网站之一，使用MongoDB。
• CERN，著名的粒子物理研究所，欧洲核子研究中心大型强子对撞机的数据使用MongoDB。

在计算机科学中, CAP定理（CAP theorem）, 又被称作 布鲁尔定理（Brewer’s theorem）, 它指出对于一个分布式计算系统来说，不可能同时满足以下三点:

• 一致性(Consistency) (所有节点在同一时间具有相同的数据)
• 可用性(Availability) (保证每个请求不管成功或者失败都有响应)
• 分隔容忍(Partition tolerance) (系统中任意信息的丢失或失败不会影响系统的继续运作)
  CAP理论的核心是：一个分布式系统不可能同时很好的满足一致性，可用性和分区容错性这三个需求，最多只能同时较好的满足两个。
  因此，根据 CAP 原理将 NoSQL 数据库分成了满足 CA 原则、满足 CP 原则和满足 AP 原则三 大类：
• CA:单点集群，满足一致性，可用性的系统，通常在可扩展性上不太强大。
• CP:满足一致性，分区容忍性的系统，通常性能不是特别高。
• AP:满足可用性，分区容忍性的系统，通常可能对一致性要求低一些。
  cap

BASE

BASE：Basically Available, Soft-state, Eventually Consistent。 由 Eric Brewer 定义。
CAP理论的核心是：一个分布式系统不可能同时很好的满足一致性，可用性和分区容错性这三个需求，最多只能同时较好的满足两个。
BASE是NoSQL数据库通常对可用性及一致性的弱要求原则:

• Basically Availble –基本可用
• Soft-state –软状态/柔性事务。 “Soft state” 可以理解为”无连接”的, 而 “Hard state” 是”面向连接”的
• Eventual Consistency –最终一致性 最终一致性， 也是是 ACID 的最终目的。

ACID vs BASE

NoSQL，指的是非关系型的数据库。NoSQL有时也称作Not Only SQL的缩写，是对不同于传统的关系型数据库的数据库管理系统的统称。
NoSQL用于超大规模数据的存储。（例如谷歌或Facebook每天为他们的用户收集万亿比特的数据）。这些类型的数据存储不需要固定的模式，无需多余操作就可以横向扩展。

为什么使用NoSQL ?

今天我们可以通过第三方平台（如：Google,Facebook等）可以很容易的访问和抓取数据。用户的个人信息，社交网络，地理位置，用户生成的数据和用户操作日志已经成倍的增加。我们如果要对这些用户数据进行挖掘，那SQL数据库已经不适合这些应用了, NoSQL数据库的发展也却能很好的处理这些大的数据。

NoSQL

RDBMS vs NoSQL

RDBMS

• 高度组织化结构化数据
• 结构化查询语言（SQL） (SQL)
• 数据和关系都存储在单独的表中。
• 数据操纵语言，数据定义语言
• 严格的一致性
• 基础事务

  NoSQL

• 代表着不仅仅是SQL
• 没有声明性查询语言
• 没有预定义的模式
• 键值对存储，列存储，文档存储，图形数据库
• 最终一致性，而非ACID属性
• 非结构化和不可预知的数据
• CAP定理
• 高性能，高可用性和可伸缩性

NoSQL的优点/缺点

优点:

• 高可扩展性
• 分布式计算
• 低成本
• 架构的灵活性，半结构化数据
• 没有复杂的关系

  缺点:

• 没有标准化
• 有限的查询功能（到目前为止）
• 最终一致是不直观的程序

NoSQL 数据库分类

向其它的RPC服务一样，GPRC的基础是服务的定义。服务定义远程调用方法的名称、传入参数和返回参数。GRPC默认使用 Protobuf描述服务

GRPC一共定义4种服务方法：
1、一元RPC(Unary RPCs )：这是最简单的定义，客户端发送一个请求，服务端返回一个结果
2、服务器流RPC（Server streaming RPCs）：客户端发送一个请求，服务端返回一个流给客户端，客户从流中读取一系列消息，直到读取所有小心
3、客户端流RPC(Client streaming RPCs )：客户端通过流向服务端发送一系列消息，然后等待服务端读取完数据并返回处理结果
4、双向流RPC(Bidirectional streaming RPCs)：客户端和服务端都可以独立向对方发送或接受一系列的消息。客户端和服务端读写的顺序是任意。

以上的服务方法定义在proto文件，如下:

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

  syntax = "proto3";
  option java_multiple_files = true;
  option java_package = "io.github.donjote.hello";
  option java_outer_classname = "HelloProto";
  service Hello {
  // A Unary RPC.
  rpc simpleRpc(Simple) returns (SimpleFeature) {}
  // A server-to-client streaming RPC.
  rpc server2ClientRpc(SimpleList) returns (stream SimpleFeature) {}
  // A client-to-server streaming RPC.
  rpc client2ServerRpc(stream Simple) returns (SimpleSummary) {}
  // A Bidirectional streaming RPC.
  rpc bindirectionalStreamRpc(stream Simple) returns (stream Simple) {}
}
message Simple {
  int32 num = 1;
  string name = 2;
}
message SimpleList {
  repeated Simple simpleList = 1;
}
message SimpleFeature {
  string name = 1;
  Simple location = 2;
}
message SimpleSummary {
  int32 feature_count = 2;
}
// 测试类
message SimpleFeatureDatabase {
  repeated SimpleFeature feature = 1;
}

同步RPC和异步RPC

GRPC 同时支持同步RPC和异步RPC。
同步RPC调用服务方法只支持流RPC（Server streaming RPCs）和一元RPC(Unary RPCs )。异步RPC调用服务方法支持4种方法。

gRPC是Go实现的：一个高性能，开源，将移动和HTTP/2放在首位通用的RPC框架， 有关详细信息，请参阅gRPC快速入门指南。

gRPC概念图

gRPC概念图

gRPC特性

基于HTTP/2协议标准

什么是HTTP/2协议

HTTP 2.0即超文本传输协议 2.0，是下一代HTTP协议（基于二进制的传输协议）。是由互联网工程任务组（IETF）的Bis (httpbis)工作小组进行开发。

HTTP/2的优点

• http2减少了网络往返传输的数量，并且用多路复用和快速丢弃不需要的流的办法来完全避免head of line blocking(线头阻塞)的困扰，降低延迟并提高安全性。
• 支持大量并行流，所以即使网站的数据分发在各处也不是问题。
• 合理利用流的优先级，可以让客户端尽可能优先收到更重要的数据。

gRPC基于强大的IDL(Interface description language)

gRPC基于ProtoBuf(Protocol Buffers)定义接口规范。

ProtoBuf是什么？

Protocol Buffers 是google提供的一种轻便、高效、简单的数据存储语言，可以用于结构化、序列化数据。

为什么要使用ProtoBuf？

• 适合应用场景：它很适合做数据存储或 RPC 数据交换格式。可用于通讯协议、数据存储等领域的语言无关、平台无关、可扩展的序列化数据结构。
• 支持语言众多（提供了完善的API）:Proto2提供了 C++、Java、Python 三种语言的 API。目前语言版本Proto3提供了更多的语言支持,包括 C++ 、C# 、GO 、JAVA、PYTHON。
• 易学易懂：protoBuf语法非常简单，掌握非常容易，便于读写。

gRPC支持众多开发语言

GRPC目前支持的开发语言已达到了10种：C, C++, Java, Go, Node.js, Python, Ruby, Objective-C, PHP and C#。并且GRPC框架已在GitHub上开源。
GitHub地址：https://github.com/grpc
JAVA GitHub地址：https://github.com/grpc/grpc-java

为什么使用gRPC

• 它使用HTTP2协议，可复用链接，更充分的利用底层TCP传输协议，并以数据流的方式传输，比其他基于HTTP1的传输速率更高。
• 它基于Proto Buffer语言,对传输数据进行压缩、系列化和结构化，易于客户端与服务端数据的读写操作，并使数据量传输变得更小、传输效率更高。
• 基于以上及其他特性，使得基于GRPC的客户端和服务端更高效的利用流和链接，从而有助于节省宽带流量、降低链接次数、提高CUP使用效率和电池的使用寿命。

TensorFlow是什么？

TensorFlow™ 是一个采用数据流图（data flow graphs），用于数值计算的开源软件库。节点（Nodes）在图中表示数学操作，图中的线（edges）则表示在节点间相互联系的多维数据数组，即张量（tensor）。它灵活的架构让你可以在多种平台上展开计算，例如台式计算机中的一个或多个CPU（或GPU），服务器，移动设备等等。TensorFlow 最初由Google大脑小组（隶属于Google机器智能研究机构）的研究员和工程师们开发出来，用于机器学习和深度神经网络方面的研究，但这个系统的通用性使其也可广泛用于其他计算领域。

TensorFlow

什么是数据流图（Data Flow Graph）?

数据流图用“结点”（nodes）和“线”(edges)的有向图来描述数学计算。“节点” 一般用来表示施加的数学操作，但也可以表示数据输入（feed in）的起点/输出（push out）的终点，或者是读取/写入持久变量（persistent variable）的终点。“线”表示“节点”之间的输入/输出关系。这些数据“线”可以输运“size可动态调整”的多维数据数组，即“张量”（tensor）。张量从图中流过的直观图像是这个工具取名为“Tensorflow”的原因。一旦输入端的所有张量准备好，节点将被分配到各种计算设备完成异步并行地执行运算。

TensorFlow的特征

• 高度的灵活性
• 真正的可移植性（Portability）
• 将科研和产品联系在一起
• 自动求微分
• 多语言支持
• 性能最优化

首先, 安装 Docker. 一旦 Docker 已经启动运行, 可以通过命令启动一个容器:

1

$ docker run -it --name tensorflow -p 8888:8888 tensorflow/tensorflow

##才云TensorFlow镜像
在官方镜像的基础上，才云科技提供的镜像进一步整合了其他机器学习工具包以及TensorFlow可视化工具TensorBoard，使用起来可以更加方便。

1
2

$ docker run -it  --name tensorflow -p 8888:8888 -p 6006:6006 \
cargo.caicloud.io/caicloud/tensorflow

在这个命令中，-p 8888:8888 将容器内运行的Jupyter服务映射到本地机器，这样在浏览器中打开localhost:8888就能看到Jupyter界面。在此镜像中运行的Jupyter是一个网页版的代码编辑器，它支持创建、上传、修改和运行Python程序。

-p 6006:6006将容器内运行的TensorFlow可视化工具TensorBoard映射到本地机器，通过在浏览器中打开localhost:6006就可以将TensorFlow在训练时的状态、图片数据以及神经网络结构等信息全部展示出来。此镜像会将所有输出到/log目录底下的日志全部可视化。

Golang并没有官方最佳管理方案，在Go的世界里存在大量的自制解决方案。go语言的包是没有中央库统一管理的，通过使用go get命令从远程代码库(github.com,goolge code 等)拉取，直接跳过中央版本库的约束，让代码的拉取直接基于源代码版本控制库，开发者间的协同直接依赖于源代码的版本控制。直接去除了库版本的概念。没有明显的包版本标识，感觉还是有点不适应，官方的建议是把外部依赖的代码全部复制到自己可控的源代码库中，进行同意管理。从而做到对依赖包的可控管理。

对于国内开发者来说，最好是能一个一个包来管理。遇到网络问题，可以通过国内镜像下载。在这样的情况之下gvt 就是一个不错的选择。它可以帮助我们把一个包以及依赖都彻底的拉到本地的代码库中，统一了团队协作过程中编译环境不一致的问题。

gvt安装方法

1

$ go get -u github.com/FiloSottile/gvt

gvt使用

安装包

1

$ gvt fetch [package]

下载包

1

$ gvt restore

包列表

1

$ gvt list

更新指定包

1

$ gvt update [package]

删除指定包

1

$ gvt delete [package]

Go 是 2009 年发布的一种简单的并行开发，且跨平台的类 C 语言。由于其强大的并行性，很适合用于网络开发中

思想

• Less can be more
• 大道至简,小而蕴真
• 让事情变得复杂很容易，让事情变得简单才难
• 深刻的工程文化

  优点

1. 自带gc。
2. 静态编译，编译好后，扔服务器直接运行。
3. 简单的思想，没有继承，多态，类等。
4. 丰富的库和详细的开发文档。
5. 语法层支持并发，和拥有同步并发的channel类型，使并发开发变得非常方便。
6. 简洁的语法，提高开发效率，同时提高代码的阅读性和可维护性。
7. 超级简单的交叉编译，仅需更改环境变量。（花了我两天时间编译一个imagemagick到arm平台）
8. 内含完善、全面的软件工程工具。Go语言自带的命令和工具相当地强大。通过它们，我们可以很轻松地完成Go语言程序的获取、编译、测试、安装、运行、运行分析等一系列工作，这几乎涉及了开发和维护一个软件的所有环节。

   主要特性

• 自动垃圾回收
• 更丰富的内置类型
• 函数多返回值
• 错误处理
• 匿名函数和闭包
• 类型和接口
• 并发编程
• 反射
• 语言交互性
• 高性能/高效开发

环境搭建

安装

1
2

$ wget https://storage.googleapis.com/golang/go1.8.3.linux-amd64.tar.gz
$ tar -C /usr/local -xzf go1.8.3.linux-amd64.tar.gz

环境变量

1

$ vim /etc/profile

添加对应的GOROOT和GOROOT的配置环境

1
2
3

export GOROOT=/usr/local/go
export GOPATH=$HOME/Projects/golang
export PATH=$PATH:$GOROOT/bin:$GOPATH/bin

之后，source /etc/profile 使得其配置文件有效.

验证

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

$ go env
GOARCH="amd64"
GOBIN=""
GOEXE=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOOS="linux"
GOPATH="/home/donjote/Projects/golang"
GORACE=""
GOROOT="/usr/local/go"
GOTOOLDIR="/usr/local/go/pkg/tool/linux_amd64"
GCCGO="gccgo"
CC="gcc"
GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build061263866=/tmp/go-build -gno-record-gcc-switches"
CXX="g++"
CGO_ENABLED="1"
PKG_CONFIG="pkg-config"
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"

机器学习(Machine Learning,ML)一门多领域交叉学科，涉及概率论、统计学、逼近学、凸分析、算法复杂度理论等多门学科。专门研究计算机怎样模拟或实现人类的学习行为，以获取新的知识或技能，重新组织已有的知识结构使之不断改善自身的性能。

它是人工智能的核心，是使计算机具有智能的根本途径，其应用遍及人工智能的各个领域，它主要使用归纳、综合不是演绎。

深度学习

深度学习是机器学习中一种基于对数据进行表征学习的方法。观测值（例如一幅图像）可以使用多种方式来表示，如每个像素强度值的向量，或者更抽象地表示成一系列边、特定形状的区域等。而使用某些特定的表示方法更容易从实例中学习任务（例如，人脸识别或面部表情识别）。深度学习的好处是用非监督式或半监督式的特征学习和分层特征提取高效算法来替代手工获取特征。

深度学习是机器学习研究中的一个新的领域，其动机在于建立、模拟人脑进行分析学习的神经网络，它模仿人脑的机制来解释数据，例如图像，声音和文本。

同机器学习方法一样，深度机器学习方法也有监督学习与无监督学习之分．不同的学习框架下建立的学习模型很是不同．例如，卷积神经网络（Convolutional neural networks，简称CNNs）就是一种深度的监督学习下的机器学习模型，而深度置信网（Deep Belief Nets，简称DBNs）就是一种无监督学习下的机器学习模型。

发展历史

发展历史

由图可以明显看出DL在从06年崛起之前经历了两个低谷，这两个低谷也将神经网络的发展分为了三个不同的阶段。

第一代神经网络

感知器(~1960）

感知器

第二代神经网络

BP（反向传播，Back-propagate）神经网络（~1985）

BP

• 它需要被标记的训练数据，但是几乎所有的数据都是未标记的。
• 学习时间不易衡量，在多层网络中，速度非常慢。
• 它陷入局部极小点而不收敛的情况极大。

  第三代神经网络

  最近的神经科学研究表明，和人类的许多认知能力相关的大脑皮层，并不显式地预处理感知信号，而是让它们通过一个复杂的模块层次结构，久而久之，就可以根据观察结果呈现的规律来表达它们。
  这一发现促进了深机器学习（DML, Deep Machine Learning）的发展。DML关注的恰恰正是是信息表达的计算模型，和大脑皮层类似。

目前DML领域有两种主流的方法：

• 卷积神经网络

  

  卷积神经网络

• 深度信念网络

  

  深度信念网络

• 命令

  $ curl -sSL https://raw.githubusercontent.com/donjote/shell-etcd/master/etcd.sh | sh -

集群验证

1. 验证集群members。在集群中的每台机器上查看members，得出的结果应该是相同的

   $ curl -L http://$(docker-machine ip etcd-node-0):2379/v2/members$ curl -L http://$(docker-machine ip etcd-node-1):2379/v2/members$ curl -L http://$(docker-machine ip etcd-node-2):2379/v2/members{"members":[{"id":"305750b374006637","name":"etcd-node-2","peerURLs":["http://192.168.99.102:2380"],"clientURLs":["http://192.168.99.102:2379"]},{"id":"c7177c3c5ff3b1b4","name":"etcd-node-0","peerURLs":["http://192.168.99.100:2380"],"clientURLs":["http://192.168.99.100:2379"]},{"id":"d5673e1f00b32e05","name":"etcd-node-1","peerURLs":["http://192.168.99.101:2380"],"clientURLs":["http://192.168.99.101:2379"]}]}

   2.某台机器上添加数据，其他机器上查看数据，得出的结果应该是相同的

   $ curl -L http://$(docker-machine ip etcd-node-0):2379/v2/keys/message -XPUT -d value="Hello World"{"action":"set","node":{"key":"/message","value":"Hello World","modifiedIndex":9,"createdIndex":9}}$ curl -L http://$(docker-machine ip etcd-node-1):2379/v2/keys/message{"action":"set","node":{"key":"/message","value":"Hello World","modifiedIndex":9,"createdIndex":9}}$ curl -L http://$(docker-machine ip etcd-node-1):2379/v2/keys/message{"action":"set","node":{"key":"/message","value":"Hello World","modifiedIndex":9,"createdIndex":9}}

etcd是一个高可用的键值存储系统，主要用于共享配置和服务发现。etcd是由CoreOS开发并维护的，灵感来自于 ZooKeeper 和 Doozer，它使用Go语言编写，并通过Raft一致性算法处理日志复制以保证强一致性。Raft是一个新的一致性算法，适用于分布式系统的日志复制，Raft通过选举的方式来实现一致性。Google的容器集群管理系统Kubernetes、开源PaaS平台Cloud Foundry和CoreOS的Fleet都广泛使用了etcd。在分布式系统中，如何管理节点间的状态一直是一个难题，etcd像是专门为集群环境的服务发现和注册而设计，它提供了数据TTL失效、数据改变监视、多值、目录监听、分布式锁原子操作等功能，可以方便的跟踪并管理集群节点的状态。

etcd的特性如下：

• 简单: 支持curl方式的用户API（HTTP+JSON）
• 安全: 可选的SSL客户端证书认证
• 快速: 单实例每秒 1000 次写操作
• 可靠: 使用Raft保证一致性

使用场景

场景一：服务发现（Service Discovery）

服务发现要解决的也是分布式系统中最常见的问题之一，即在同一个分布式集群中的进程或服务，要如何才能找到对方并建立连接。本质上来说，服务发现就是想要了解集群中是否有进程在监听udp或tcp端口，并且通过名字就可以查找和连接。要解决服务发现的问题，需要有下面三大支柱，缺一不可。

一个强一致性、高可用的服务存储目录。基于Raft算法的etcd天生就是这样一个强一致性高可用的服务存储目录。

一种注册服务和监控服务健康状态的机制。用户可以在etcd中注册服务，并且对注册的服务设置key TTL，定时保持服务的心跳以达到监控健康状态的效果。

一种查找和连接服务的机制。通过在etcd指定的主题下注册的服务也能在对应的主题下查找到。为了确保连接，我们可以在每个服务机器上都部署一个Proxy模式的etcd，这样就可以确保能访问etcd集群的服务都能互相连接。

服务发现示意图

下面我们来看服务发现对应的具体场景。

微服务协同工作架构中，服务动态添加。随着Docker容器的流行，多种微服务共同协作，构成一个相对功能强大的架构的案例越来越多。透明化的动态添加这些服务的需求也日益强烈。通过服务发现机制，在etcd中注册某个服务名字的目录，在该目录下存储可用的服务节点的IP。在使用服务的过程中，只要从服务目录下查找可用的服务节点去使用即可。

服务协同工作

PaaS平台中应用多实例与实例故障重启透明化。PaaS平台中的应用一般都有多个实例，通过域名，不仅可以透明的对这多个实例进行访问，而且还可以做到负载均衡。但是应用的某个实例随时都有可能故障重启，这时就需要动态的配置域名解析（路由）中的信息。通过etcd的服务发现功能就可以轻松解决这个动态配置的问题。

多平台多实例透明化

场景二：消息发布与订阅

在分布式系统中，最适用的一种组件间通信方式就是消息发布与订阅。即构建一个配置共享中心，数据提供者在这个配置中心发布消息，而消息使用者则订阅他们关心的主题，一旦主题有消息发布，就会实时通知订阅者。通过这种方式可以做到分布式系统配置的集中式管理与动态更新。

应用中用到的一些配置信息放到etcd上进行集中管理。这类场景的使用方式通常是这样：应用在启动的时候主动从etcd获取一次配置信息，同时，在etcd节点上注册一个Watcher并等待，以后每次配置有更新的时候，etcd都会实时通知订阅者，以此达到获取最新配置信息的目的。

分布式搜索服务中，索引的元信息和服务器集群机器的节点状态存放在etcd中，供各个客户端订阅使用。使用etcd的key TTL功能可以确保机器状态是实时更新的。

分布式日志收集系统。这个系统的核心工作是收集分布在不同机器的日志。收集器通常是按照应用（或主题）来分配收集任务单元，因此可以在etcd上创建一个以应用（主题）命名的目录P，并将这个应用（主题相关）的所有机器ip，以子目录的形式存储到目录P上，然后设置一个etcd递归的Watcher，递归式的监控应用（主题）目录下所有信息的变动。这样就实现了机器IP（消息）变动的时候，能够实时通知到收集器调整任务分配。

系统中信息需要动态自动获取与人工干预修改信息请求内容的情况。通常是暴露出接口，例如JMX接口，来获取一些运行时的信息。引入etcd之后，就不用自己实现一套方案了，只要将这些信息存放到指定的etcd目录中即可，etcd的这些目录就可以通过HTTP的接口在外部访问。

消息发布和订阅

场景三：负载均衡

在场景一中也提到了负载均衡，本文所指的负载均衡均为软负载均衡。分布式系统中，为了保证服务的高可用以及数据的一致性，通常都会把数据和服务部署多份，以此达到对等服务，即使其中的某一个服务失效了，也不影响使用。由此带来的坏处是数据写入性能下降，而好处则是数据访问时的负载均衡。因为每个对等服务节点上都存有完整的数据，所以用户的访问流量就可以分流到不同的机器上。

etcd本身分布式架构存储的信息访问支持负载均衡。etcd集群化以后，每个etcd的核心节点都可以处理用户的请求。所以，把数据量小但是访问频繁的消息数据直接存储到etcd中也是个不错的选择，如业务系统中常用的二级代码表（在表中存储代码，在etcd中存储代码所代表的具体含义，业务系统调用查表的过程，就需要查找表中代码的含义）。

利用etcd维护一个负载均衡节点表。etcd可以监控一个集群中多个节点的状态，当有一个请求发过来后，可以轮询式的把请求转发给存活着的多个状态。类似KafkaMQ，通过ZooKeeper来维护生产者和消费者的负载均衡。同样也可以用etcd来做ZooKeeper的工作。

负载均衡

场景四：分布式通知与协调

这里说到的分布式通知与协调，与消息发布和订阅有些相似。都用到了etcd中的Watcher机制，通过注册与异步通知机制，实现分布式环境下不同系统之间的通知与协调，从而对数据变更做到实时处理。实现方式通常是这样：不同系统都在etcd上对同一个目录进行注册，同时设置Watcher观测该目录的变化（如果对子目录的变化也有需要，可以设置递归模式），当某个系统更新了etcd的目录，那么设置了Watcher的系统就会收到通知，并作出相应处理。

通过etcd进行低耦合的心跳检测。检测系统和被检测系统通过etcd上某个目录关联而非直接关联起来，这样可以大大减少系统的耦合性。

通过etcd完成系统调度。某系统有控制台和推送系统两部分组成，控制台的职责是控制推送系统进行相应的推送工作。管理人员在控制台作的一些操作，实际上是修改了etcd上某些目录节点的状态，而etcd就把这些变化通知给注册了Watcher的推送系统客户端，推送系统再作出相应的推送任务。

通过etcd完成工作汇报。大部分类似的任务分发系统，子任务启动后，到etcd来注册一个临时工作目录，并且定时将自己的进度进行汇报（将进度写入到这个临时目录），这样任务管理者就能够实时知道任务进度。

分布式协同工作

场景五：分布式锁

因为etcd使用Raft算法保持了数据的强一致性，某次操作存储到集群中的值必然是全局一致的，所以很容易实现分布式锁。锁服务有两种使用方式，一是保持独占，二是控制时序。

保持独占即所有获取锁的用户最终只有一个可以得到。etcd为此提供了一套实现分布式锁原子操作CAS（CompareAndSwap）的API。通过设置prevExist值，可以保证在多个节点同时去创建某个目录时，只有一个成功。而创建成功的用户就可以认为是获得了锁。

控制时序，即所有想要获得锁的用户都会被安排执行，但是获得锁的顺序也是全局唯一的，同时决定了执行顺序。etcd为此也提供了一套API（自动创建有序键），对一个目录建值时指定为POST动作，这样etcd会自动在目录下生成一个当前最大的值为键，存储这个新的值（客户端编号）。同时还可以使用API按顺序列出所有当前目录下的键值。此时这些键的值就是客户端的时序，而这些键中存储的值可以是代表客户端的编号。

分布式锁

场景六：分布式队列

分布式队列的常规用法与场景五中所描述的分布式锁的控制时序用法类似，即创建一个先进先出的队列，保证顺序。

另一种比较有意思的实现是在保证队列达到某个条件时再统一按顺序执行。这种方法的实现可以在/queue这个目录中另外建立一个/queue/condition节点。

condition可以表示队列大小。比如一个大的任务需要很多小任务就绪的情况下才能执行，每次有一个小任务就绪，就给这个condition数字加1，直到达到大任务规定的数字，再开始执行队列里的一系列小任务，最终执行大任务。
condition可以表示某个任务在不在队列。这个任务可以是所有排序任务的首个执行程序，也可以是拓扑结构中没有依赖的点。通常，必须执行这些任务后才能执行队列中的其他任务。

分布式队列

场景七：集群监控与Leader竞选

通过etcd来进行监控实现起来非常简单并且实时性强。

前面几个场景已经提到Watcher机制，当某个节点消失或有变动时，Watcher会第一时间发现并告知用户。
节点可以设置TTL key，比如每隔30s发送一次心跳使代表该机器存活的节点继续存在，否则节点消失。
这样就可以第一时间检测到各节点的健康状态，以完成集群的监控要求。

另外，使用分布式锁，可以完成Leader竞选。这种场景通常是一些长时间CPU计算或者使用IO操作的机器，只需要竞选出的Leader计算或处理一次，就可以把结果复制给其他的Follower。从而避免重复劳动，节省计算资源。

这个的经典场景是搜索系统中建立全量索引。如果每个机器都进行一遍索引的建立，不但耗时而且建立索引的一致性不能保证。通过在etcd的CAS机制同时创建一个节点，创建成功的机器作为Leader，进行索引计算，然后把计算结果分发到其它节点。

Leader竞选

为什么用etcd而不用ZooKeeper？

etcd实现的这些功能，ZooKeeper都能实现。那么为什么要用etcd而非直接使用ZooKeeper呢？

相较之下，ZooKeeper有如下缺点：

1. 复杂。ZooKeeper的部署维护复杂，管理员需要掌握一系列的知识和技能；而Paxos强一致性算法也是素来以复杂难懂而闻名于世；另外，ZooKeeper的使用也比较复杂，需要安装客户端，官方只提供了Java和C两种语言的接口。
2. Java编写。这里不是对Java有偏见，而是Java本身就偏向于重型应用，它会引入大量的依赖。而运维人员则普遍希望保持强一致、高可用的机器集群尽可能简单，维护起来也不易出错。]
3. 发展缓慢。Apache基金会项目特有的“Apache Way”在开源界饱受争议，其中一大原因就是由于基金会庞大的结构以及松散的管理导致项目发展缓慢。

而etcd作为一个后起之秀，其优点也很明显。

1. 简单。使用Go语言编写部署简单；使用HTTP作为接口使用简单；使用Raft算法保证强一致性让用户易于理解。
2. 数据持久化。etcd默认数据一更新就进行持久化。
3. 安全。etcd支持SSL客户端安全认证。

最后，etcd作为一个年轻的项目，真正告诉迭代和开发中，这既是一个优点，也是一个缺点。优点是它的未来具有无限的可能性，缺点是无法得到大项目长时间使用的检验。然而，目前CoreOS、Kubernetes和CloudFoundry等知名项目均在生产环境中使用了etcd，所以总的来说，etcd值得你去尝试。

Facebook发布的新一代包管理工具，旨在解决以往使用npm作为包管理会遇到的一些问题。从其官方介绍可以看到其重点强调的3个点：快、可靠、安全。

Yarn特性

离线模式

以前安装过的包可以在没有任何互联网连接的情况下重新安装。

确定性

不管安装顺序如何，相同的依赖关系将在每台机器上以相同的方式安装。

网络性能

Yarn 有效地对请求进行排队，并避免 request waterfalls， 以便最大限度地利用网络。

多个 Registries

支持从 npm 或 Bower 安装包，并保持安装包的工作流程相同。

网络恢复

单个请求失败不会导致安装失败，而会重试请求。

扁平模式

将不兼容版本的依赖项解析为单个版本，以避免重复下载。

安装方法

1

$ sudo npm i -g yarn

设置淘宝镜像

1
2

$ yarn config set registry https://registry.npm.taobao.org --global
$ yarn config set disturl https://npm.taobao.org/dist --global

用法

初始化一个新的项目

$ yarn init

添加一个依赖包

$ yarn add [package]$ yarn add [package]@[version]$ yarn add [package]@[tag]

更新一个依赖包

$ yarn upgrade [package]$ yarn upgrade [package]@[version]$ yarn upgrade [package]@[tag]

移除一个依赖包

$ yarn remove [package]

安装项目所有的依赖包

$ yarn或$ yarn install

Yarn命令列表

Electron 可以让你使用纯 JavaScript 调用丰富的原生 APIs 来创造桌面应用。你可以把它看作一个专注于桌面应用的 Node.js 的变体，而不是 Web 服务器。

这不意味着 Electron 是绑定了 GUI 库的 JavaScript。相反，Electron 使用 web 页面作为它的 GUI，所以你能把它看作成一个被 JavaScript 控制的，精简版的 Chromium 浏览器。

进程

主进程

在 Electron 里，运行 package.json 里 main 脚本的进程被称为主进程。在主进程运行的脚本可以以创建 web 页面的形式展示 GUI。

渲染进程

由于 Electron 使用 Chromium 来展示页面，所以 Chromium 的多进程结构也被充分利用。每个 Electron 的页面都在运行着自己的进程，这样的进程我们称之为渲染进程。

在一般浏览器中，网页通常会在沙盒环境下运行，并且不允许访问原生资源。然而，Electron 用户拥有在网页中调用 Node.js 的 APIs 的能力，可以与底层操作系统直接交互。

主进程与渲染进程的区别

主进程使用 BrowserWindow 实例创建页面。每个 BrowserWindow 实例都在自己的渲染进程里运行页面。当一个 BrowserWindow 实例被销毁后，相应的渲染进程也会被终止。

主进程管理所有页面和与之对应的渲染进程。每个渲染进程都是相互独立的，并且只关心他们自己的页面。

由于在页面里管理原生 GUI 资源是非常危险而且容易造成资源泄露，所以在页面调用 GUI 相关的 APIs 是不被允许的。如果你想在网页里使用 GUI 操作，其对应的渲染进程必须与主进程进行通讯，请求主进程进行相关的 GUI 操作。

在 Electron，提供几种方法用于主进程和渲染进程之间的通讯。像 ipcRenderer 和 ipcMain 模块用于发送消息， remote 模块用于 RPC 方式通讯。这些内容都可以在一个 FAQ 中查看 how to share data between web pages。

查看 Nodejs安装并配置淘宝镜像

Electron的安装

在~/.npmrc里做如下设置

1

electron_mirror="https://npm.taobao.org/mirrors/electron/"

用下面的命令安装

1

$ sudo npm install -g electron

打包输出工具

为了方便最终成果输出，建议安装electron-packager工具，安装也很简单，建议以下面的命令全局安装。

1

$ sudo npm install -g electron-packager

事务(Transaction)是访问并可能更新数据库中各种数据项的一个程序执行单元(unit)。事务通常由高级数据库操纵语言或编程语言（如SQL，C++或Java）书写的用户程序的执行所引起，并用形如begin transaction和end transaction语句（或函数调用）来界定。事务由事务开始(begin transaction)和事务结束(end transaction)之间执行的全体操作组成。
事务是应用程序中一系列严密的操作，所有操作必须成功完成，否则在每个操作中所作的所有更改都会被撤消。也就是事务具有原子性，一个事务中的一系列的操作要么全部成功，要么一个都不做。
事务的结束有两种，当事务中的所以步骤全部成功执行时，事务提交。如果其中一个步骤失败，将发生回滚操作，撤消撤消之前到事务开始时的所以操作。

事务的 ACID

事务具有四个特征：原子性（ Atomicity ）、一致性（ Consistency ）、隔离性（ Isolation ）和持续性（ Durability ）。这四个特性简称为 ACID 特性。

原子性

事务的原子性指的是，事务中包含的程序作为数据库的逻辑工作单位，它所做的对数据修改操作要么全部执行，要么完全不执行。这种特性称为原子性。
事务的原子性要求，如果把一个事务可看作是一个程序，它要么完整的被执行，要么完全不执行。就是说事务的操纵序列或者完全应用到数据库或者完全不影响数据库。这种特性称为原子性。

假如用户在一个事务内完成了对数据库的更新，这时所有的更新对外部世界必须是可见的，或者完全没有更新。前者称事务已提交，后者称事务撤消（或流产）。DBMS必须确保由成功提交的事务完成的所有操纵在数据库内有完全的反映，而失败的事务对数据库完全没有影响。

一致性

事务的一致性指的是在一个事务执行之前和执行之后数据库都必须处于一致性状态。这种特性称为事务的一致性。假如数据库的状态满足所有的完整性约束，就说该数据库是一致的。

一致性处理数据库中对所有语义约束的保护。假如数据库的状态满足所有的完整性约束，就说该数据库是一致的。例如，当数据库处于一致性状态S1时，对数据库执行一个事务，在事务执行期间假定数据库的状态是不一致的，当事务执行结束时，数据库处在一致性状态S2。

分离性

分离性指并发的事务是相互隔离的。即一个事务内部的操作及正在操作的数据必须封锁起来，不被其它企图进行修改的事务看到。 分离性是DBMS针对并发事务间的冲突提供的安全保证。DBMS可以通过加锁在并发执行的事务间提供不同级别的分离。假如并发交叉执行的事务没有任何控制，操纵相同的共享对象的多个并发事务的执行可能引起异常情况。

DBMS可以在并发执行的事务间提供不同级别的分离。分离的级别和并发事务的吞吐量之间存在反比关系。较多事务的可分离性可能会带来较高的冲突和较多的事务流产。流产的事务要消耗资源，这些资源必须要重新被访问。因此，确保高分离级别的DBMS需要更多的开销。

持久性

持久性意味着当系统或介质发生故障时，确保已提交事务的更新不能丢失。即一旦一个事务提交，DBMS保证它对数据库中数据的改变应该是永久性的，耐得住任何系统故障。持久性通过数据库备份和恢复来保证。

持久性意味着当系统或介质发生故障时，确保已提交事务的更新不能丢失。即对已提交事务的更新能恢复。一旦一个事务被提交，DBMS必须保证提供适当的冗余，使其耐得住系统的故障。所以，持久性主要在于DBMS的恢复性能。

数学定义

在数学里，幂等有两种主要的定义：

• 在某二元运算下，幂等元素是指被自己重复运算(或对于函数是为复合)的结果等于它自己的元素。例如，乘法下唯一两个幂等实数为0和1。 即 s * s = s
• 某一元运算为幂等的时，其作用在任一元素两次后会和其作用一次的结果相同。例如，高斯符号便是幂等的，即f(f(x)) = f(x)。

HTTP规范的定义

在HTTP/1.1规范中幂等性的定义是：

Methods can also have the property of “idempotence” in that (aside from error or expiration issues) the side-effects of N > 0 identical requests is the same as for a single request.

从定义上看，HTTP方法的幂等性是指一次和多次请求某一个资源应该具有同样的副作用。幂等性属于语义范畴，正如编译器只能帮助检查语法错误一样，HTTP规范也没有办法通过消息格式等语法手段来定义它，这可能是它不太受到重视的原因之一。但实际上，幂等性是分布式系统设计中十分重要的概念，而HTTP的分布式本质也决定了它在HTTP中具有重要地位。

HTTP的幂等性

HTTP协议本身是一种面向资源的应用层协议，但对HTTP协议的使用实际上存在着两种不同的方式：一种是RESTful的，它把HTTP当成应用层协议，比较忠实地遵守了HTTP协议的各种规定；另一种是SOA的，它并没有完全把HTTP当成应用层协议，而是把HTTP协议作为了传输层协议，然后在HTTP之上建立了自己的应用层协议。本文所讨论的HTTP幂等性主要针对RESTful风格的，不过正如上一节所看到的那样，幂等性并不属于特定的协议，它是分布式系统的一种特性；所以，不论是SOA还是RESTful的Web API设计都应该考虑幂等性。下面将介绍HTTP GET、DELETE、PUT、POST四种主要方法的语义和幂等性。

HTTP GET方法用于获取资源，不应有副作用，所以是幂等的。

HTTP DELETE方法用于删除资源，有副作用，但它应该满足幂等性。

比较容易混淆的是HTTP POST和PUT。POST和PUT的区别容易被简单地误认为“POST表示创建资源，PUT表示更新资源”；而实际上，二者均可用于创建资源，更为本质的差别是在幂等性方面。在HTTP规范中对POST和PUT是这样定义的：

The POST method is used to request that the origin server accept the entity enclosed in the request as a new subordinate of the resource identified by the Request-URI in the Request-Line …… If a resource has been created on the origin server, the response SHOULD be 201 (Created) and contain an entity which describes the status of the request and refers to the new resource, and a Location header.

The PUT method requests that the enclosed entity be stored under the supplied Request-URI. If the Request-URI refers to an already existing resource, the enclosed entity SHOULD be considered as a modified version of the one residing on the origin server. If the Request-URI does not point to an existing resource, and that URI is capable of being defined as a new resource by the requesting user agent, the origin server can create the resource with that URI.

POST所对应的URI并非创建的资源本身，而是资源的接收者。两次相同的POST请求会在服务器端创建两份资源，它们具有不同的URI；所以，POST方法不具备幂等性。而PUT所对应的URI是要创建或更新的资源本身。对同一URI进行多次PUT的副作用和一次PUT是相同的；因此，PUT方法具有幂等性。

幂等的实现方案

查询操作

查询一次和查询多次，在数据不变的情况下，查询结果是一样的。select是天然的幂等操作

删除操作

删除操作也是幂等的，删除一次和多次删除都是把数据删除。(注意可能返回结果不一样，删除的数据不存在，返回0，删除的数据多条，返回结果多个)

唯一索引，防止新增脏数据

比如：支付宝的资金账户，支付宝也有用户账户，每个用户只能有一个资金账户，怎么防止给用户创建资金账户多个，那么给资金账户表中的用户ID加唯一索引，所以一个用户新增成功一个资金账户记录

要点：
唯一索引或唯一组合索引来防止新增数据存在脏数据（当表存在唯一索引，并发时新增报错时，再查询一次就可以了，数据应该已经存在了，返回结果即可）

token机制，防止页面重复提交

业务要求：

页面的数据只能被点击提交一次

发生原因：

由于重复点击或者网络重发，或者nginx重发等情况会导致数据被重复提交

解决办法：

集群环境：采用token加redis（redis单线程的，处理需要排队）
单JVM环境：采用token加redis或token加jvm内存

处理流程：

1. 数据提交前要向服务的申请token，token放到redis或jvm内存，token有效时间
2. 提交后后台校验token，同时删除token，生成新的token返回

   token特点：

   要申请，一次有效性，可以限流

注意：
redis要用删除操作来判断token，删除成功代表token校验通过，如果用select+delete来校验token，存在并发问题，不建议使用

悲观锁

获取数据的时候加锁获取
select * from table_xxx where id=’xxx’ for update;
注意：id字段一定是主键或者唯一索引，不然是锁表，会死人的
悲观锁使用时一般伴随事务一起使用，数据锁定时间可能会很长，根据实际情况选用

乐观锁

乐观锁只是在更新数据那一刻锁表，其他时间不锁表，所以相对于悲观锁，效率更高。
乐观锁的实现方式多种多样可以通过version或者其他状态条件：

1. 通过版本号实现
   update table_xxx set name=#name#,version=version+1 where version=#version#
   如下图(来自网上)：

   

   乐观锁

2. 通过条件限制
   update table_xxx set avai_amount=avai_amount-#subAmount# where avai_amount-#subAmount# >= 0
   要求：quality-#subQuality# >= ，这个情景适合不用版本号，只更新是做数据安全校验，适合库存模型，扣份额和回滚份额，性能更高

注意：乐观锁的更新操作，最好用主键或者唯一索引来更新,这样是行锁，否则更新时会锁表，上面两个sql改成下面的两个更好
update table_xxx set name=#name#,version=version+1 where id=#id# and version=#version#
update table_xxx set avai_amount=avai_amount-#subAmount# where id=#id# and avai_amount-#subAmount# >= 0

分布式锁

还是拿插入数据的例子，如果是分布是系统，构建全局唯一索引比较困难，例如唯一性的字段没法确定，这时候可以引入分布式锁，通过第三方的系统(redis或zookeeper)，在业务系统插入数据或者更新数据，获取分布式锁，然后做操作，之后释放锁，这样其实是把多线程并发的锁的思路，引入多多个系统，也就是分布式系统中得解决思路。

要点：某个长流程处理过程要求不能并发执行，可以在流程执行之前根据某个标志(用户ID+后缀等)获取分布式锁，其他流程执行时获取锁就会失败，也就是同一时间该流程只能有一个能执行成功，执行完成后，释放分布式锁(分布式锁要第三方系统提供)

select + insert

并发不高的后台系统，或者一些任务JOB，为了支持幂等，支持重复执行，简单的处理方法是，先查询下一些关键数据，判断是否已经执行过，在进行业务处理，就可以了

注意：核心高并发流程不要用这种方法

状态机幂等

在设计单据相关的业务，或者是任务相关的业务，肯定会涉及到状态机(状态变更图)，就是业务单据上面有个状态，状态在不同的情况下会发生变更，一般情况下存在有限状态机，这时候，如果状态机已经处于下一个状态，这时候来了一个上一个状态的变更，理论上是不能够变更的，这样的话，保证了有限状态机的幂等。

对外提供接口的api如何保证幂等

如银联提供的付款接口：需要接入商户提交付款请求时附带：source来源，seq序列号
source+seq在数据库里面做唯一索引，防止多次付款，(并发时，只能处理一个请求)

重点：
对外提供接口为了支持幂等调用，接口有两个字段必须传，一个是来源source，一个是来源方序列号seq，这个两个字段在提供方系统里面做联合唯一索引，这样当第三方调用时，先在本方系统里面查询一下，是否已经处理过，返回相应处理结果；没有处理过，进行相应处理，返回结果。注意，为了幂等友好，一定要先查询一下，是否处理过该笔业务，不查询直接插入业务系统，会报错，但实际已经处理了。

总结：

幂等性应该是合格程序员的一个基因，在设计系统时，是首要考虑的问题，尤其是在像支付宝，银行，互联网金融公司等涉及的都是钱的系统，既要高效，数据也要准确，所以不能出现多扣款，多打款等问题，这样会很难处理，用户体验也不好

什么是敏捷开发

敏捷开发（Agile Development）不是指某一种具体的方法论、过程或框架，而是一组价值观和原则。是一种以人为核心、迭代、循序渐进的开发方法。

怎么理解呢？

• 首先，敏捷并不是一门具体的技术，而是一种理念或者说是一种思想。也就是一种软件开发的流程，它会指导我们用规定的环节去一步一步完成项目的开发；而这种开发方式的主要驱动核心是人；它采用的是迭代式开发；
• 其次，敏捷开发都具有以下共同的特征：
  1. 迭代式开发
  2. 增量交付
  3. 开发团队和用户反馈推动产品开发
  4. 持续集成
  5. 开发团队自我管理
• 最后，相比于“传统”的瀑布开发模式，敏捷开发是一种“现代”的开发模式。

为什么说是以人为核心？

我们大部分人都学过瀑布开发模型，它是以文档为驱动的，为什么呢？因为在瀑布的整个开发过程中，要写大量的文档，把需求文档写出来后，开发人员都是根据文档进行开发的，一切以文档为依据；而敏捷开发它只写有必要的文档，或尽量少写文档，敏开发注重的是人与人之间，面对面的交流，所以它强调以人为核心。

什么是迭代？

迭代是指把一个复杂且开发周期很长的开发任务，分解为很多小周期可完成的任务，这样的一个周期就是一次迭代的过程；同时每一次迭代都可以生产或开发出一个可以交付的软件产品。

敏捷开发宣言

《敏捷宣言》

我们通过身体力行和帮助他人来揭示更好的软件开发方式。经由这项工作，我们形成了如下价值观：

个体与交互 重于 过程和工具
可用的软件 重于 完备的文档
客户协作 重于 合同谈判
响应变化 重于 遵循计划

在每对比对中，后者并非全无价值，但我们更看重前者

敏捷宣言是对敏捷的高度总结和升华，即使现在不理解也没有问题，在实践的过程中我们会逐渐对它有一个深刻的认识。

敏捷开发十二原则

在敏捷开发中，我们遵循以下准则：

1. 我们的最高目标是，通过尽早和持续地交付有价值的软件来满足客户。
2. 欢迎对需求提出变更——即使是在项目开发后期。要善于利用需求变更，帮助客户获得竞争优势。
3. 要不断交付可用的软件，周期从几周到几个月不等，且越短越好
4. 项目过程中，业务人员与开发人员必须在一起工作。
5. 要善于激励项目人员，给他们以所需要的环境和支持，并相信他们能够完成任务。
6. 无论是团队内还是团队间，最有效的沟通方法是面对面的交谈。
7. 可用的软件是衡量进度的主要指标。
8. 敏捷过程提倡可持续的开发。项目方、开发人员和用户应该能够保持恒久稳定的进展速度。
9. 对技术的精益求精以及对设计的不断完善将提升敏捷性。
10. 要做到简洁，即尽最大可能减少不必要的工作。这是一门艺术。
11. 最佳的架构、需求和设计出自于自组织的团队。
12. 团队要定期反省如何能够做到更有效，并相应地调整团队的行为。

关于Scrum和XP

前面说了敏捷它是一种指导思想或开发方式，但是它没有明确告诉我们到底采用什么样的流程进行开发，而Scrum和XP就是敏捷开发的具体方式了，你可以采用Scrum方式也可以采用XP方式；Scrum和XP的区别是，Scrum偏重于过程，XP则偏重于实践，但是实际中，两者是结合一起应用的，这里主要讲Scrum。

什么是Scrum？

Scrum的英文意思是橄榄球运动的一个专业术语，表示“争球”的动作；把一个开发流程的名字取名为Scrum，我想你一定能想象出你的开发团队在开发一个项目时，大家像打橄榄球一样迅速、富有战斗激情、人人你争我抢地完成它，你一定会感到非常兴奋的。
而Scrum就是这样的一个开发流程，运用该流程，你就能看到你团队高效的工作。

【Scrum开发流程中的三大角色】

产品负责人（Product Owner）

主要负责确定产品的功能和达到要求的标准，指定软件的发布日期和交付的内容，同时有权力接受或拒绝开发团队的工作成果。

流程管理员（Scrum Master）

主要负责整个Scrum流程在项目中的顺利实施和进行，以及清除挡在客户和开发工作之间的沟通障碍，使得客户可以直接驱动开发。

开发团队（Scrum Team）

主要负责软件产品在Scrum规定流程下进行开发工作，人数控制在5~10人左右，每个成员可能负责不同的技术方面，但要求每成员必须要有很强的自我管理能力，同时具有一定的表达能力；成员可以采用任何工作方式，只要能达到Sprint的目标。

Scrum流程图

Scrum流程图

什么是Sprint？

Sprint是短距离赛跑的意思，这里面指的是一次迭代，而一次迭代的周期是1个月时间（即4个星期），也就是我们要把一次迭代的开发内容以最快的速度完成它，这个过程我们称它为Sprint。

如何进行Scrum开发？

1. 我们首先需要确定一个Product Backlog（按优先顺序排列的一个产品需求列表），这个是由Product Owner 负责的；
2. Scrum Team根据Product Backlog列表，做工作量的预估和安排；
3. 有了Product Backlog列表，我们需要通过 Sprint Planning Meeting（Sprint计划会议） 来从中挑选出一个Story作为本次迭代完成的目标，这个目标的时间周期是1~4个星期，然后把这个Story进行细化，形成一个Sprint Backlog；
4. Sprint Backlog是由Scrum Team去完成的，每个成员根据Sprint Backlog再细化成更小的任务（细到每个任务的工作量在2天内能完成）；
5. 在Scrum Team完成计划会议上选出的Sprint Backlog过程中，需要进行 Daily Scrum Meeting（每日站立会议），每次会议控制在15分钟左右，每个人都必须发言，并且要向所有成员当面汇报你昨天完成了什么，并且向所有成员承诺你今天要完成什么，同时遇到不能解决的问题也可以提出，每个人回答完成后，要走到黑板前更新自己的 Sprint burn down（Sprint燃尽图）；
6. 做到每日集成，也就是每天都要有一个可以成功编译、并且可以演示的版本；很多人可能还没有用过自动化的每日集成，其实TFS就有这个功能，它可以支持每次有成员进行签入操作的时候，在服务器上自动获取最新版本，然后在服务器中编译，如果通过则马上再执行单元测试代码，如果也全部通过，则将该版本发布，这时一次正式的签入操作才保存到TFS中，中间有任何失败，都会用邮件通知项目管理人员；
7. 当一个Story完成，也就是Sprint Backlog被完成，也就表示一次Sprint完成，这时，我们要进行 Srpint Review Meeting（演示会议），也称为评审会议，产品负责人和客户都要参加（最好本公司老板也参加），每一个Scrum Team的成员都要向他们演示自己完成的软件产品（这个会议非常重要，一定不能取消）；
8. 最后就是 Sprint Retrospective Meeting（回顾会议），也称为总结会议，以轮流发言方式进行，每个人都要发言，总结并讨论改进的地方，放入下一轮Sprint的产品需求中；

下面是运用Scrum开发流程中的一些场景图：

产品需求

上图是一个 Product Backlog 的示例。

每日站会

上图就是每日的站立会议了，参会人员可以随意姿势站立，任务看板要保证让每个人看到，当每个人发言完后，要走到任务版前更新自己的燃尽图。

任务看板

任务看版包含 未完成、正在做、已完成 的工作状态，假设你今天把一个未完成的工作已经完成，那么你要把小卡片从未完成区域贴到已完成区域。

任务看板

每个人的工作进度和完成情况都是公开的，如果有一个人的工作任务在某一个位置放了好几天，大家都能发现他的工作进度出现了什么问题（成员人数最好是5~7个，这样每人可以使用一种专用颜色的标签纸，一眼就可以从任务版看出谁的工作进度快，谁的工作进度慢）

计划纸牌

上图可不是扑克牌，它是计划纸牌，它的作用是防止项目在开发过程中，被某些人所领导。

怎么用的呢？比如A程序员开发一个功能，需要5个小时，B程序员认为只需要半小时，那他们各自取相应的牌，藏在手中，最后摊牌，如果时间差距很大，那么A和B就可以讨论A为什么要5个小时…

一个免费在线敏捷开发工具截图

鱼骨-敏捷开发

安装 Node.js 方式多种多样，最简单的方式是在Node.js 官网 下载可执行程序直接安装即可。

• 对于 Mac，可以使用 Homebrew 进行安装：

  brew install node

  更多安装方式可参考 Node.js 官方信息
• 安装完成后，可以使用以下命令检测是否安装成功:

  $ node -vv6.11.0$ npm -v3.10.10

配置Node.js

使用淘宝的 npm 镜像

• 通过config命令

  $ npm config set registry https://registry.npm.taobao.org   $ npm info underscore （如果上面配置正确这个命令会有字符串response）

• 命令行指定

  $ npm --registry https://registry.npm.taobao.org info underscore    

• 编辑 ~/.npmrc 加入下面内容

  registry = https://registry.npm.taobao.org

目前主流的应用大体分成三类：Native App（原生APP）, Web App(H5开发模式), Hybrid App（混合模式）.

App三种开发模式

Native App特点:

• 性能好
• 完美的用户体验
• 开发成本高，无法跨平台
• 升级困难(审核),维护成本高

Web App特点:

• 开发成本低,更新快,版本升级容易,自动升级
• 跨平台，Write Once , Run Anywhere
• 无法调用系统级的API
• 临时入口，用户留存度低
• 性能差,体验差,设计受限制
• 相比Native App，Web App体验中受限于以上5个因素：网络环境，渲染性能，平台特性，受限于浏览器，系统限制。

Hybrid App特点:

• Native App 和 Web App 折中的方案，保留了 Native App 和 Web App 的优点。

• 但是还是性能差。页面渲染效率低，在Webview中绘制界面，实现动画，资源消耗都比较大,受限于技术,网速等因素

  

Hybrid App开发框架

weex

简介

weex是阿里巴巴公司与2016年6月开源的一种用于构建移动跨平台的UI框架

特点:

• Lightweight:轻量级,语法简单,易于使用
• Extendable:可扩展,丰富内置组件,可扩展的API,
• High Performance:高性能
• 核心理念:
  • Write Once Run Everywhere
  • 基于JS开发框架:
  • weex基于vue.js

React Native

简介:

Facebook在2015年3月在F8开发者大会上开源的跨平台UI框架

核心理念:

LEARN ONCE, WRITE ANYWHERE

基于JS开发框架:

React Native基于React

知识拓展:vue.js和React

Vue:

是一个构建数据驱动的 web 界面的库。Vue.js 的目标是通过尽可能简单的 API 实现响应的数据绑定和组合的视图组件.

React:

基于HTML的前端界面开发正变得越来越复杂，其本质问题基本都可以归结于如何将来自于服务器端或者用户输入的动态数据高效的反映到复杂的用户界面上。而来自Facebook的React框架正是完全面向此问题的一个解决方案，按官网描述，其出发点为：用于开发数据不断变化的大型应用程序。相比传统型的前端开发，React开辟了一个相当另类的途径，实现了前端界面的高效率高性能开发。

Vue.js和React的异同:

Vue和React的区别

Weex和React Native的异同

相同点:

• 都采用Web的开发模式，使用JS开发；
• 都可以直接在Chrome中调试JS代码；
• 都支持跨平台的开发；
• 都可以实现hot reload，边更新代码边查看效果；

不同点:

JS引擎

什么是JS引擎

学习成本

环境配置：

ReactNative需要按照文档安装配置很多依赖的工具，相对比较麻烦。 weex安装cli之后就可以使用

vue vs react:上面已经做过对比

react模板JSX学习使用有一定的成本 vue更接近常用的web开发方式，模板就是普通的html，数据绑定使用mustache风格，样式直接使用css

社区支持

• Weex开源较晚，互联网上相关资料还比较少，社区规模较小；
• React Native社区则比较活跃，可以参考的项目和资料也比较丰富

一张图:从渲染时间,内存使用,CPU占用,帧率(图形处理器每秒钟能够刷新几次,高的帧率可以得到更流畅、更逼真的动画。每秒钟帧数 （fps） 愈多，所显示的动作就会愈流畅。)

安装docker

参考官方文档

安装docker-compose

参考官方文档

搭建Harbor

• 下载:

  wget https://github.com/vmware/harbor/releases/download/v1.1.2/harbor-online-installer-v1.1.2.tgz

• 解压:

  tar zvxf harbor-online-installer-v1.1.2.tgz

• 修改配置:

  cd harborvim harbor.cfg

  配置样例如下：

  ## Configuration file of Harbor#The IP address or hostname to access admin UI and registry service.#DO NOT use localhost or 127.0.0.1, because Harbor needs to be accessed by external clients.# 指定 hostname，一般为IP，或者域名，用于登录 Web UI 界面hostname = 120.12.34.45#The protocol for accessing the UI and token/notification service, by default it is http.#It can be set to https if ssl is enabled on nginx.# URL 访问方式，SSL 需要配置 nginxui_url_protocol = http#Email account settings for sending out password resetting emails.# 邮件相关信息配置，如忘记密码发送邮件email_server = smtp.xxxxxx.comemail_server_port = 465email_username = reg@mritd.meemail_password = xxxxxxemail_from = docker <reg@mritd.me>email_ssl = true##The password of Harbor admin, change this before any production use.# 默认的 Harbor 的管理员密码，管理员用户名默认 adminharbor_admin_password = Harbor12345##By default the auth mode is db_auth, i.e. the credentials are stored in a local database.#Set it to ldap_auth if you want to verify a user's credentials against an LDAP server.# 指定 Harbor 的权限验证方式，Harbor 支持本地的 mysql 数据存储密码，同时也支持 LDAPauth_mode = db_auth#The url for an ldap endpoint.# 如果采用了 LDAP，此处填写 LDAP 地址ldap_url = ldaps://ldap.mydomain.com#The basedn template to look up a user in LDAP and verify the user's password.# LADP 验证密码的方式(我特么没用过这么高级的玩意)ldap_basedn = uid=%s,ou=people,dc=mydomain,dc=com#The password for the root user of mysql db, change this before any production use.# mysql 数据库 root 账户密码db_password = root123#Turn on or off the self-registration feature# 是否允许开放注册self_registration = on#Turn on or off the customize your certicate# 允许自签名证书customize_crt = on#fill in your certicate message# 自签名证书信息crt_country = CNcrt_state = Statecrt_location = CNcrt_organization = mritdcrt_organizationalunit = mritdcrt_commonname = mritd.mecrt_email = reg.mritd.me#####

• 启动

  sudo ./install

• 登录
  Harbor 默认管理员用户为 admin ，密码在 harbor.cfg 中设置过，默认的是 Harbor12345 ，可直接登陆

Monolithic架构

Monolithic比较适合小项目

Monolithic架构优点

• 开发简单直接，集中式管理, 基本不会重复开发
• 功能都在本地，没有分布式的管理开销和调用开销。

  Monolithic架构缺点

  它的缺点也非常明显，特别对于互联网公司来说（不一一列举了）：
• 开发效率低：所有的开发在一个项目改代码，递交代码相互等待，代码冲突不断
• 代码维护难：代码功能耦合在一起，新人不知道何从下手
• 部署不灵活：构建时间长，任何小修改必须重新构建整个项目，这个过程往往很长
• 稳定性不高：一个微不足道的小问题，可以导致整个应用挂掉
• 扩展性不够：无法满足高并发情况下的业务需求

微服务架构

什么是微服务

相对于单体（Monolithic）应用而言，微服务是采用一组服务的方式来构建一个应用，服务独立部署在不同的进程中，不同服务通过一些轻量级交互机制来通信，例如 RPC、HTTP 等,服务可独立扩展伸缩，每个服务定义了明确的边界，不同的服务甚至可以采用不同的编程语言来实现，由独立的团队来维护。

微服务的价值

• 首先，在功能不变的情况下，应用被分解为多个可管理的服务，每个服务开发、运维变得简单。
• 其次，每个微服务独立部署，开发者不在需要协调其他服务部署对本服务的影响，这可以加快部署精度。
• 最后，每个服务可以自行决定自己的容量。

虽然对于一些简单的、规模有限的应用而言，单体架构仍然是有意义的。微服务是应用开发和部署的一个不同的方法。它非常适合许多现代的云应用对于敏捷性、扩展规模和可靠性的要求。一个微服务应用被分解成独立的部件，被称为“微服务”。“微服务”协同工作，以便提供应用的整体功能。“微服务”这一术语强调一个事实，那就是应用应该是由足够小的服务所组成，以便真正体现独立性，使得每个微服务实现单一的功能。此外，每个微服务都有明确的合同（API合同）——通常是RESTful 的——以便其他微服务能够与之进行交流和分享数据。微服务也必须能够彼此独立地进行版本更新。这种松耦合正是对一个应用实现快速而可靠地演化的支撑。下图显示了一个单体应用是如何被分解为不同的微服务的。

微服务架构

微服务的特点

• 小, 且专注于做⼀件事情
• 进程独立
• 轻量级的通信机制
• 松耦合
• 独立部署

领域驱动设计： 应用程序功能分解可以通过Eric Evans在《领域驱动设计》中明确定义的规则实现；每个团队负责与一个领域或业务功能相关的全部开发；团队拥有全系列的开发人员，具备用户界面、业务逻辑和持久化存储等方面的开发技能；
单一职责原则： 每个服务应该负责该功能的一个单独的部分，这是面向对象设计的SOLID原则原则之一；
明确发布接口： 每个服务都会发布一个定义明确的接口，而且保持不变；服务消费者只关心接口，而对于被消费的服务没有任何运行依赖；
独立部署、升级、扩展和替换： 每个服务都可以单独部署及重新部署而不影响整个系统。这使得服务很容易升级，每个服务都可以沿着《架构即未来》一书定义的AKF扩展立方体的X轴和Z轴进行扩展；
可以异构/采用多种语言：　每个服务的实现细节都与其它服务无关，这使得服务之间能够解耦，团队可以针对每个服务选择最合适的开发语言、持久化存储、工具和方法；
轻量级通信：　服务通信使用轻量级的通信协议，例如，同步的REST，异步的AMQP、STOMP、MQTT等。

微服务架构的思想本质跟互联网的思想是一致的。它的组件对外发布的服务视同HTTP协议，采用HTTP Rest API的方式来进行。很多开放平台的API服务，基本都采用了Http API的方式进行服务的发布和管理。

微服务优点

• 每个微服务都很小，这样能聚焦一个指定的业务功能或业务需求。
• 微服务能够被小团队单独开发，这个小团队是2到5人的开发人员组成。
• 微服务是松耦合的，是有功能意义的服务，无论是在开发阶段或部署阶段都是独立的。
• 微服务能使用不同的语言开发。
• 微服务允许容易且灵活的方式集成自动部署，通过持续集成工具，如Jenkins, bamboo 。
• 一个团队的新成员能够更快投入生产。
• 微服务易于被一个开发人员理解，修改和维护，这样小团队能够更关注自己的工作成果。无需通过合作才能体现价值。
• 微服务允许你利用融合最新技术。
• 微服务只是业务逻辑的代码，不会和HTML,CSS 或其他界面组件混合。
• 微服务能够即时被要求扩展。
• 微服务能部署中低端配置的服务器上。
• 易于和第三方集成。
• 每个微服务都有自己的存储能力，可以有自己的数据库。也可以有统一数据库。

微服务架构的缺点

• 微服务架构可能带来过多的操作。
• 需要DevOps技巧 (http://en.wikipedia.org/wiki/DevOps).
• 可能双倍的努力。
• 分布式系统可能复杂难以管理。
• 因为分布部署跟踪问题难。
• 服务数量增加，管理复杂性增加。

常见的微服务组件

• 服务注册:服务提供方将自己调用地址注册到服务注册中心，让服务调用方能够方便地找到自己。
• 服务发现:服务调用方从服务注册中心找到自己需要调用的服务的地址。
• 负载均衡:服务提供方一般以多实例的形式提供服务，负载均衡功能能够让服务调用方连接到合适的服务节点。并且，节点选择的工作对服务调用方来说是透明的。
• 服务网关:服务网关是服务调用的唯一入口，可以在这个组件是实现用户鉴权、动态路由、灰度发布、A/B测试、负载限流等功能。
• 配置中心:将本地化的配置信息（properties,
  xml, yaml等）注册到配置中心，实现程序包在开发、测试、生产环境的无差别性，方便程序包的迁移。
• API管理:以方便的形式编写及更新API文档，并以方便的形式供调用者查看和测试。
• 集成框架:微服务组件都以职责单一的程序包对外提供服务，集成框架以配置的形式将所有微服务组件（特别是管理端组件）集成到统一的界面框架下，让用户能够在统一的界面中使用系统。
• 分布式事务:对于重要的业务，需要通过分布式事务技术（TCC、高可用消息服务、最大努力通知）保证数据的一致性。具有代表性的有spring transaction
• 调用链:记录完成一个业务逻辑时调用到的微服务，并将这种串行或并行的调用关系展示出来。在系统出错时，可以方便地找到出错点。具有代表性的有pinpoint.
• 支撑平台:系统微服务化后，系统变得更加碎片化，系统的部署、运维、监控等都比单体架构更加复杂，那么，就需要将大部分的工作自动化。现在，可以通过Docker等工具来中和这些微服务架构带来的弊端。 例如:持续集成、蓝绿发布、健康检查、性能健康等等。严重点，以我们两年的实践经验，可以这么说，如果没有合适的支撑平台或工具，就不要使用微服务架构。