亚马逊的实践

• 程序模块通过service interface 开放
• 信息接口 通过接口
• 除此之外 没有其他通信方式
• 任何技术都可以使用
• 对外界开放的设计
• 不这样做的人 会被炒鱿鱼

配额和限流

• 分布式团队架构
• 分布式服务查错不易
• 没有专职的测试人员 也没有专职的运维人员
• 运维优先 崇尚简化和自动化
• 内部服务和外部服务一致

需要注意的问题

异构系统的不标准问题

• 软件和应用不标准
• 通讯协议不标准
• 数据格式不标准
• 开发和运维的过程和方法不标准

系统架构中的服务依赖性问题

木桶短板效应 整个SLA由最差的那个服务所决定

故障发生的概率更大

• 出现故障不可怕 故障恢复时间过长才可怕
• 出现故障不可怕 故障影响面过大才可怕

多层架构的运维复杂度更大

go语言的体会

• 语言简单 上手快
• 并行和异步编程几乎无痛点 goroutine channel
• lib库 麻雀虽小 五脏俱全
• c语言的理念和python的姿态
• 存在诸多的问题 垃圾回收 异常处理 泛型编程等

• 有没有一个好的社区
• 有没有工业化的标准
• 有没有一个或者多个杀手级应用
• 学习难度是否低 上手是否快
• 提高开发效率的开发框架
• 技术公司作为后盾
• 解决软件开发中的痛点（java解决内存管理问题）

PaaS是承上启下的关键技术

1. 软件生产线的问题
2. 分布式服务化的问题
3. 提高服务的可用性SLA
4. 软件能力的复用

挤出时间来干这些“逆人性”的事情 渴望程度

• 使用语言开发 可维护的程序
• 如何进行后续的优化
• 前后端分离

• 计算机提升社会运作效率并不是靠前端来完成的 而是靠自动化来完成的 所以后端的业务逻辑和计算 才是业务的核心 所以我从技术支持 测试这种支持性的工作中脱离出来 想做一些产出性的工作

• 开发测试工具 运维系统和工具 开发项目管理软件 只有到开发上 你才有更好的发展

中心化的设计思想

中心化的设计思想很简单，按照角色分工 大体上两种

一种是中心节点 另外就是普通节点 如果中心节点出现问题 则集群会崩溃

去中心化的设计

不存在单点故障

完全意义的真正去中心化的分布式系统并不多见。相反，外部开来去中心化单工作机制采用了中心化设计思想的分布式系统正在不断涌出。在这种架构下，集群中的领导是被动态选择出来的，而不是认为预先置顶的，而且集群发声故障的情况下，集群的成员会自发的举行“会议”选举新的“领导”主持工作。最典型的案例就是ZooKeeper及Go语言实现的Etcd

分布式环境的问题有：

1. 通信异常：从集中式向分布式演变过程中，必然会引入网络因素，而由于网络本身的不可靠性，因此也引入了额外的问题。分布式系统需要在各个节点之间进行网络通信，因此当网络通信设备故障就会导致无法顺利完成一次网络通信，就算各节点的网络通信正常，但是消息丢失和消息延时也是非常普遍的事情。
2. 网络分区（脑裂）：网络发生异常情况导致分布式系统中部分节点之间的网络延时不断增大，最终导致组成分布式系统的所有节点，只有部分节点能够正常通行，而另一些节点则不能。我们称这种情况叫做网络分区（脑裂），当网络分区出现时，分布式系统会出现多个局部小集群（多个小集群可能又会产生多个master节点），所以分布式系统要求这些小集群要能独立完成原本需要整个分布式系统才能完成的功能，这就对分布式一致性提出了非常大的挑战。
3. 节点故障：节点宕机是分布式环境中的常态，每个节点都有可能会出现宕机或僵死的情况，并且每天都在发生。
4. 三态：由于网络不可靠的原因，因此分布式系统的每一次请求，都存在特有的“三态”概念，即：成功，失败与超时。在集中式单机部署中，由于没有网络因素，所以程序的每一次调用都能得到“成功”或者“失败”的响应，但是在分布式系统中，网络不可靠，可能就会出现超时的情况。可能在消息发送时丢失或者在响应过程中丢失，当出现超时情况时，网络通信的发起方是无法确定当前请求是否被成功处理的，所以这也是分布式事务的难点。

基本可用(basically available)：

基本可用是指分布式系统在出现不可预知故障的时候，允许损失部分可用性——但请注意，这绝不等价于系统不可用。以下两个就是“基本可用”的典型例子。

1. 响应时间上的损失：正常情况下，一个在线搜索引擎需要在0.5秒之内返回给用户相应的查询结果，但由于出现故障（比如系统部分机房发生断电或断网故障），查询结果的响应时间增加到了1～2秒。

2. 功能上的损失：正常情况下，在一个电子商务网站上进行购物，消费者几乎能够顺利地完成每一笔订单，但是在一些节日大促购物高峰的时候，由于消费者的购物行为激增，为了保护购物系统的稳定性，部分消费者可能会被引导到一个降级页面。

弱状态(soft state)

弱状态也称为软状态，和硬状态相对，是指允许系统中的数据存在中间状态，并认为该中间状态的存在不会影响系统的整体可用性，即允许系统在不同节点的数据副本之间进行数据同步的过程存在延时。

最终一致性(eventual consistency)

最终一致性强调的是系统中所有的数据副本，在经过一段时间的同步后，最终能够达到一个一致的状态。因此，最终一致性的本质是需要系统保证最终数据能够达到一致，而不需要实时保证系统数据的强一致性。

注意：最终一致性是一种特殊的弱一致性：系统能够保证在没有其他新的更新操作的情况下，数据最终一定能够达到一致的状态，因此所有客户端对系统的数据访问都能够获取到最新的值。同时，在没有发生故障的前提下，数据达到一致状态的时间延迟，取决于网络延迟、系统负载和数据复制方案设计等因素。

在实际工程实践中，最终一致性存在以下五类主要变种。

1 因果一致性（Causal consistency）

因果一致性是指，如果进程A在更新完某个数据项后通知了进程B，那么进程B之后对该数据项的访问都应该能够获取到进程A更新后的最新值，并且如果进程B要对该数据项进行更新操作的话，务必基于进程A更新后的最新值，即不能发生丢失更新情况。与此同时，与进程A无因果关系的进程C的数据访问则没有这样的限制。

2 读己之所写（Read your writes）

读己之所写是指，进程A更新一个数据项之后，它自己总是能够访问到更新过的最新值，而不会看到旧值。也就是说，对于单个数据获取者来说，其读取到的数据，一定不会比自己上次写入的值旧。因此，读己之所写也可以看作是一种特殊的因果一致性。

3 会话一致性（Session consistency）

会话一致性将对系统数据的访问过程框定在了一个会话当中：系统能保证在同一个有效的会话中实现“读己之所写”的一致性，也就是说，执行更能操作之后，客户端能够在同一个会话中始终读取到该数据项的最新值。

4 单调读一致性（Monotonic read consistency）

单调读一致性是指如果一个进程从系统中读取出一个数据项的某个值后，那么系统对于该进程后续的任何数据访问都不应该返回更旧的值。

5 单调写一致性（Monotonic write consistency）

单调写一致性是指，一个系统需要能够保证来自同一个进程的写操作被顺序地执行。

事实上，最终一致性并不是只有那些大型分布式系统才涉及的特性，许多现代的关系型数据库都采用了最终一致性模型。在现代关系型数据库中，大多都会采用同步和异步方式来实现主备数据复制技术。1 .在同步方式中，数据的复制过程通常是更新事务的一部分，因此在事务完成后，主备数据库的数据就会达到一致（强一致性）。2. 而在异步方式中，备库的更新往往会存在延时，这取决于事务日志在主备数据库之间传输的时间长短，如果传输时间过长或者甚至在日志传输过程中出现异常导致无法及时将事务应用到备库上，那么很显然，从备库中读取的数据将是旧的，因此就出现了数据不一致的情况。当然，无论是采用多次重试还是人为数据订正，关系型数据库还是能够保证最终数据达到一致——这就是系统提供最终一致性保证的经典案例。

总的来说，BASE理论面向的是大型高可用可扩展的分布式系统，和传统事务的ACID特性是相反的，它完全不同于ACID的强一致性模型，而是提出通过牺牲强一致性来获得可用性，并允许数据在一段时间内是不一致的，但最终达到一致状态。但同时，在实际的分布式场景中，不同业务单元和组件对数据一致性的要求是不同的，因此在具体的分布式系统架构设计过程中，ACID特性与BASE理论往往又会结合在一起使用。

分布式学习的理论基础

• Consistency 一致性:
  这里的一致性是针对于分布式读写的。对于一个分布式系统，当一条数据写成功，那么无论我怎么使用这个系统，我都应当能马上读取到这条最新的数据。
  不一致性的例子:我更新了一条微博，而我的关注者还不能看到。
• Avalilability 可用性:
  是指系统应当随时可用，在reasonable的时间内返回reasonable的结果。
  一个反例:我更新了一条微博，我的关注者在刷我微博的时候显示对方正在更新微博，请稍后再试，或者显示一直在读取中。
• Partition Toleranc 分区容忍性:
  分布式环境中数据必然会被划分成多个区分到不同的机器上，不同的机器之间会有数据交换。
  而机器一多某台机器发生发生故障的概率就会比较高，而且机器间数据的交换依赖于网络，网络也很有可能会有延时、丢包之类的问题。
  分区容忍性就要求在分布式系统要考虑到分布式环境的复杂性的前提下能正常提供服务。

分布式的挑战来自不确定性，不确定计算机什么时候crash、断电，不确定磁盘什么时候损坏，不确定每次网络通信要延迟多久，也不确定通信对端是否处理了发送的消息。而分布式的规模放大了这个不确定性，不确定性是令人讨厌的，所以有诸多的分布式理论、协议来保证在这种不确定性的情况下，系统还能继续正常工作。

负载均衡：

　　　　Nginx：高性能、高并发的web服务器；功能包括负载均衡、反向代理、静态内容缓存、访问控制；工作在应用层

　　　　LVS： Linux virtual server，基于集群技术和Linux操作系统实现一个高性能、高可用的服务器；工作在网络层

webserver：

　　　　Java：Tomcat，Apache，Jboss

　　　　Python：gunicorn、uwsgi、twisted、webpy、tornado

service：　　

　　　　SOA、微服务、spring boot，django

容器：

　　　　docker，kubernetes

cache：

　　　　memcache、redis等

协调中心：

　　　　zookeeper、etcd等

　　　　zookeeper使用了Paxos协议Paxos是强一致性，高可用的去中心化分布式。zookeeper的使用场景非常广泛，之后细讲。

rpc框架：

　　　　grpc、dubbo、brpc

　　　　dubbo是阿里开源的Java语言开发的高性能RPC框架，在阿里系的诸多架构中，都使用了dubbo + spring boot

消息队列：

　　　　kafka、rabbitMQ、rocketMQ、QSP

　　　　消息队列的应用场景：异步处理、应用解耦、流量削锋和消息通讯

实时数据平台：

　　　　storm、akka

离线数据平台：

　　　　hadoop、spark

　　　　PS: apark、akka、kafka都是scala语言写的，看到这个语言还是很牛逼的

dbproxy：

　　　　cobar也是阿里开源的，在阿里系中使用也非常广泛，是关系型数据库的sharding + replica 代理

db：

　　　　mysql、oracle、MongoDB、HBase、pg

搜索：

　　　　elasticsearch、solr

日志：

　　　　rsyslog、elk、flume 　　　　

　　　
通用的关系型数据库设计理论，需要满足四种指标:

• Atomicity 原子性:
• Consistency 一致性:
• Isolation 独立性:
• Durability 持久性:

一般情况下 cap只能保证其中的两个 没法全部兼得

做技术有没有前途？

目前中国的基础技术还在发展当中 技术能力不足

西方“精耕细作” 比拼技术

技术人员跟从和被驱动

• 野蛮开采
• 资源整合
• 精耕细作
• 发明创造

发展自己的核心技术 提高技术领导力

技术不是问题 技术领导力才是问题！！！

• 能够发现问题
• 解决问题 比较优缺点
• 技术决定
• 更优雅、更简单、更容易的方式来解决问题
• 提高扩展性、重用性、可维护性
• 正确管理团队
• 创新能力

• 追求核心基础技术
• 追逐自动化的工具和技术
• 解放生产力
• 开发高效可重用组件
• 坚持高于社会主流的技术标准和要求

严于律己