分布式架构的演进

架构的本质

架构的本质就是对系统进行有序化重构，是系统不断进化

架构是怎么实现无序到有序的呢？基本的手段就是分和合，拆分的结果是开发人员能够做到业务聚焦、技能聚焦，实现开发敏捷，合的结果是系统变得柔性，可以因需而变，实现业务敏捷。

架构的分类

1.业务架构从概念层面帮助开发人员更好的理解系统，比如业务流程、业务模块、输入输出、业务域

2.应用架构从逻辑层面帮助开发落地系统，如数据交互关系、应用形式、交互方式，使得整个系统逻辑上更容易理解，例如SOA就属于应用架构的范畴

3.技术架构主要解决计数平台选型、如操作系统、中间件、设备、多机房、水平扩展、高可用等问题

系统或者架构首先都是为人服务的，系统的有序度高。逻辑合理，业务概念清晰是第一位。具体架构设计师，首要关注业务架构和应用架构，这个设计架构的时候要特别注意。

大型网站的架构演进

从一个电商网站开始

1）应用服务和数据库在同一服务器

2）单机负载告警，数据库与应用分离

- 为什么这么分？从计算机本身的角度来考虑的话，一个请求的访问到处理最终到返回，性能瓶颈只会是：CPU、文件IO、网络IO、内存等因素。一台计算机这些维度都是有性能瓶颈的，如果某个资源消耗躲过，通常会造成系统的响应速度较慢，而增加一台机器，使的数据库的IO和CPU资源独占一台机器从而增加性能。
- 各个资源的消耗原因
1.主要是上下文的切换，因为每个CPU核心在同一时刻只能执行一个线程，而CPU的调度有几种当时，比如抢占式和轮训等，以抢占式为例，每个线程会分配一定的执行时间，当达到执行时间、线程中有IO阻塞或者有高优先级的线程要执行时。CPU会切换执行其他线程。而在切换的过程中，需要存储当前线程的执行状态并恢复要执行的线程状态，这个过程就是上下文切换。比如IO、锁等待等场景下也会触发上下文切换，当上下文切换过多会会造成内核占用比较多的CPU。
2.文件IO，比如频繁的日志写入，磁盘本身的处理速度较慢。都会造成IO性能问题。
3.网络IO,带宽不够
4.内存，包括内存溢出、内存泄漏、内存不足
实际上不管是应用层的调优还是硬件的升级也好。无非是这几个因素的调整。

3）应用服务器复杂告警，如何让应用服务器走向集群

- 这里考虑通过水平扩偶然拿过来进行优化，把单机变成集群，但这个时候会抛出两个问题
  1.最终用户对应这两个服务器访问的选择问题
  对于这个问题，可以采用DNS解决，也可以通过负载均衡设备来解决
  2.session的问题？

水平和垂直扩容

对于大型的分布式架构胃炎，我们一直在追求一种简单、优雅的方式来应对访问量和数据量的增长。而这种方式通常指的是不需要改动软件程序，仅仅通过硬件升级或者增加机器就可以解决。而这种就是分布式架构吓得伸缩设计

伸缩分为垂直伸缩和水平伸缩两种

垂直伸缩：表示通过升级或者增加单台机器的硬件来支持访问量以及数据量增长的方式，垂直伸缩 的好处在于技术难度比较低，运营和改动成本也相对较低。但是缺点是机器性能是由瓶颈的，同时升级高性能的小型机或者大型机，成本是非常大的。

增加CPU的核心数：增加CPU后系统的服务能力能够得到大的增长，比如响应速度、同时可以处理的线程数。但是引入CPU后也会带来一些显著的问题

1.锁竞争加剧；多个线程同时运行访问某个共享数据，那么就涉及到锁竞争，锁竞争激烈是会导致很多线程都在等待锁，所以即使增加CPU也无法让线程得到更快的处理。当然这里可以通过调优手段来降低锁竞争

2.支撑并发请求的线程数是固定的，那么即使增加CPU。系统的服务能力也不会得到提升

3.对于单线程任务，多核心CPU是没有太大的作用的

增加内存：增加内存可以直接提成系统的响应速度；当然，也有可能达不到效果，就是如果JVM堆内存是固定的。

水平伸缩：通过增加机器来支撑访问量及数据量增长的方式，成为水平伸缩，水平伸缩理论上来说没有瓶颈，但是缺点是技术要求比较高，同时给运维带来了更大的挑战

	水平伸缩和垂直伸缩各有优缺点，我们在实际使用过程中都会对两者做结合，一方面要考虑硬件升级的成本，一面要考虑软件改造的成本。

引入负载均衡设备

服务路由，基于负载均衡设备来实现（但是会带来session相关的问题）
负载均衡算法
  - 轮询（Round Robin）法
  将请求按顺序轮流分配到后台服务器上，均衡的对待每一台服务器，而不关心服务器实际的连接数和当前的系统负载
  缺点：当集群中服务器硬件配置不同、性能差别大时，无法区别对待
  - 随机算法
  通过系统随机函数，根据后台服务器列表的大小值来随机选取其中一台进行访问。随着调用量的增大，其实际效果越来越接近于平均分配流量到后台的每一台服务器，也就是轮训法的效果
  优点：简单使用，不需要额外的配置和算法。
  缺点：随机数的特点是在数据量大到一定量时才能保证均衡，如果请求量有限的话，可能会达不到均衡负载的要求。
  - 源地址哈希法
  根据服务消费者请求客户端的IP地址，通过哈希函数计算得到一个哈希值，将这个哈希值和服务器列表的大小进行取模运算，得到的结果便是要访问的服务器地址的序号。采用源地址哈希法进行负载均衡，相同的IP客户端，如果服务器列表不变，将映射到同一个后台服务器进行访问。
  - 加权轮询（Weight Round Robin）法
  不同的后台服务器可能机器的配置和当前系统的负载并不相同，因此他们的抗压能力也不一样。跟配置高、负载低的机器分配更高的权重，使其能处理更多的请求，而配置低、负载高的机器，则给其分配较低的权重，降低其系统负载，加权轮询很好的处理了这一问题，并将请求按照顺序且根据权重分配给后端。
  - 最小连接数
  前面几种方式都是通过请求次数的合理分配最大可能提高服务器的利用率，但实际上，请求次数的均衡并不能代表负载的均衡。所以，引入了最小连接数法。他正是根据后端服务器当前的连接情况，动态的选取其中当前积压连接数最少的一台服务器来处理当前请求，尽可能的提高后台服务器利用率，将负载合理的分流到每一台服务器。

session问题

我们打开一个网页，基本上需要浏览器和web服务器进行多次交互，我们都知道http协议本身是无状态的，这也是http协议设计的初衷，无论是客户端还是服务器端都没有必要记录彼此过去的行为，每一次请求之间都是独立的。好比一个顾客和一个自动售货机之间的关系一样。

而实际上，我们很多的场景都需要带有状态的特性，因此我们引入了session+cookie机制来记住每次请求的会话。

在会话开始时，给当前会话分配一个唯一的会话标识，然后通过cookie把这个标识告诉浏览器。以后在每次请求的时候，浏览器都会带上这个会话标识来告诉web服务器请求属于哪个会话。在web服务器上，各个会话有独立的存储，保存不同会话信息。如果遇到禁用cookie的情况，一般的做法就是把这个会话标识放到URL的参数中。

而当我们应用服务器从一台变成两台后，就会遇到session问题。

分布式环境下的session共享

session共享的解决方案：

服务器实现的session复制或session共享，这类型的共享session是和服务器紧密相关的,我们在web服务器之间增加了会话数据的同步，通过同步就能保证了不同web服务器之间Session数据的一致。一般应用容器都支持Session Replication方式。

存在问题：

1.同步session数据造成了网络带宽的开销。只要session数据有变化，就需要将数据同步到所有其他的机器上，机器越多，同步带来的网络带宽开销就越大。

2.每台Web服务器都要保存所有Session数据，如果整个集群的Session数据很多（很多人同时访问）的话，每台机器用于保存Session数据的内容占用会很严重。

这个方案是靠应用容器来完成Session的复制从而解决Session的问题的，应用本身并不关心这个事情。这个方案不适合集群机器多的场景。

利用成熟的技术做session复制，比如12306使用的gemfire，比较常见的内存数据库如Redis.

Session数据不保存到本机而且存放到一个集合中存储的地方，修改Session也是发生在集合中存储的地方。Web服务器使用Session从集中存储的地方读取。这样保证了不同web服务器读取到的session数据都是一样的。存储Session的具体方式可以是数据库。

存在问题：
1.读写Session数据引入了网络操作，这相对于本机的数据读取来说，问题就在于存在时间延迟和不稳定性，不过我们的通讯基本上都是内网，问题不大。
2.如果集中存储Session的机器或者集群有问题，就会影响到我们的应用。
相比于Session Replication,当web服务器数量比较大、Session数比较多的时候，这个集中存储方案的优势是非常明显的。

将session维护在客户端

很容易就想到利用cookir，但是客户端存在风险，数据不安全，而且可以存放的数据量比较小，所以将session维护在客户端还要对session中的信息加密。

我们的session数据放到Cookie中，然后在web服务器上从Cookie中生成对应的Session数据。相对前面的集中存储方案，不会依赖外部的存储系统，也就不存在从外部系统获取，写入session数据的网络延迟、不稳定性了。

存在问题：
安全性。session数据本来都是服务端数据，而这个方案就是让这些服务端数据到了外部网络及客户端，因此存在安全性上的问题。我们可以对写入的Cookie的Session数据加密，不过相对于安全来说，物理上不能接触才是安全的。

数据库压力变大，读写分离

这个结构的变化会带来两个问题:
1.数据库如何同步
我们希望通过读库来分担主库上读的压力，那么就需要解决的是怎么复制到读库的问题。数据库系统一般都提供了数据复制的功能，我们可以直接使用数据库系统自身的机制。不同的数据库系统有不同的支持，比如Mysql支持Master+slave的结构提供数据复制机制
2.应用对数据源如何路由
对于应用来说，增加一个读库对结构变化产生了一定的影响，也就是我们的应用需要根据不同的情况来选择不同的数据库源。

搜索引擎其实就是一个读库

对于一个电商网站来说，网站需要提供用户实时检索的功能。而使用搜索引擎，不仅能大大提高检索速度。还能减轻数据库的压力，而搜索引擎最重要的工作，就是需要根据被搜索的数据来构建索引，而随着被搜索的数据的变化，索引也需要进行相应变化。

搜索集群的使用方式和读库的使用方式是一样的，只是构建索引的过程基本都是需要我们自己来实现。可以从两个维度对搜索引擎构建索引的方式进行规划，一个是按照全量/增量划分。一种是按照实时/非实时划分。
全量方式用于第一次建立索引。可能是新建，也可能是重建。而增量的方式是在全量的基础上持续更新索引。
实时和非实时体现在索引更新的时间上，实时是最好的，非实时主要考虑到对数据源头的保护。
总的来说，搜索引擎技术解决了站内搜索时某些场景下的读的问题，提供了更好地查询效率。

加速数据读取的利器—缓存及分布式存储

在大型网站中，基本还是那个就是在解决存储和计算的问题，索引存储是一个很重要的支撑系统。

虽然前可以使用触发器、存储过程，把业务逻辑放在数据库中去做。但在未来的发展中会带来很多的麻烦，比如数据量大了以后，要做分库分表操作，同时，业务发展到一定的体量之后，对存储的需求不能完全通过关系型数据库来满足。

分布式文件系统

对于一些图片、大文件，使用数据库就不合适了，所以我们会采用分布式文件系统来实现文件存储，分布式文件系统有很多产品、比如淘宝的TFS、google的GFS。还有开源的HDFS。

NoSQL

在大型网站中，关系型数据库可以解决大部分问题，但是对于不同内容的特征、访问特性、事务特性等对于存储的要求是不一样的。NoSQL是定位于文件系统和SQL关系数据库之间的范畴。

数据缓存

大型网站内部都会用到一些数据缓存，主要是用于分担数据库的读的压力李，缓存系统一般是用来保存和查询键值对的。应用系统中一般会把热点数据放入到缓存，而缓存的填充也应该是由应用系统完成。如果数据不存在，则在从数据库放入缓存中。随着时间的推移，当缓存容量不够需要清除数据时，最近不被访问的数据就会被清理掉。还有一种方式就是在数据库可的数据发生变化后，主动把数据放入到缓存中，这样的好处是数据变化时能够及时更新缓存的数据，不会造成读取失效。

页面缓存

除数据缓存外，我们还可以对页面做缓存，数据缓存可以加速应用在响应请求时的数据读取速度。但是最终展示给用户的还是几面，有些动态产生的页面或者访问量特别高的页面，我们会对页面或者内容做一些缓存。

弥补关系型数据库的不足，引入分布式存储

我们应用最多的主要是关系型数据库，但是在有些场景中，关系型数据库不是很合适。所以我们引入了分布式存储系统，比如redis、mongoDB、HBase等。

根据不同的场景和数据结构类型，选择合适的分布式系统可以极大的提高性能。分布式系统通过集群提供一个高容量、高并发访问、数据冗余的支持。

读写分离后，数据库又遇瓶颈

通过读写分离以及在某些场景用分布式存储替换关系型数据库的的方式，能够降低主库的压力，解决数据存储方面的问题，不过随着业务的发展，我们的主库也会遇到瓶颈。尽管增加了缓存、读写分离的方式，但是数据库的压力仍然在持续增加，因此我们可以对数据垂直拆分和水平拆分解决数据库压力问题。

专库专用，数据垂直拆分

垂直拆分的意思是把数据库中不同的业务数据拆分到不同的数据库中。

不同的数据从原来的一个数据库拆分到多个数据库中，那么就需要考虑到如何处理原来单机跨业务的事务
1.使用分布式事务解决
2.去掉事务或者不追求强事务的支持
对数据进行垂直拆分后，解决了把所有业务数据放在一个人数据库中的压力问题，并且也可以根据不同的业务的特点进行更多的优化

垂直拆分后，遇到瓶颈，数据水平拆分

	与垂直拆分对应的还有数据水平拆分，数据水平拆分就是把同一个表的数据拆分成两个数据库中，产生数据库水平拆分的原因是某个业务的数据表的数据量或者更新量达到了单个数据库的瓶颈，这个时候就可以把表拆到两个或者多个数据库中。
	数据水平拆分与读写分离的区别是，读写分离解决的是读压力大的问题，对于数据量大或者更新量大的情况不起作用。
	数据水平拆分和数据垂直拆分的区别，垂直拆分是把不同的表拆分到不同的数据库，而水平拆分是把同一个表拆分到不同的数据库中。
	两个表的结构是相同的，而每个库中的数据只涵盖了一部分的用户，两个数据库合并就相当于没有拆分之前的数据表。

水平拆分带来的影响

1.sql路由问题，需要根据一个条件来决定当前请求发送到哪个数据库中
2.主键的处理，不能采用自增id，需要全局id
3.由于同一个业务的数据被拆分到不同的数据库，因此涉及到一些查询需要跨两个数据库获取，如果数据量太大并且需要分页，就很难处理了。

数据库问题解决后，应用面对的挑战

随着业务的发展，应用的功能越来越多，应用也会越来越大，我们需要将应用拆开，从一个应用变成两个甚至多个。

第一种方式
根据业务的特性把应用拆分，在我们的例子中，主要业务功能分三个部分、用户、商品、交易。我们可以把原来的一个应用拆成分别以交易和商品为主的两个应用，对于交易和商品都会有设计使用用户的地方，我们让这两个系统自己完成涉及用户的工作，而类似用户注册、登录等基础的用户工作，可以暂时交给两个系统之一来完成。
这里面涉及到如何保障代码的一致以及如何对其他模块提供复用也是需要解决的问题。
第二种方式：服务化道路
我们把应用层分为三层，处于最上端的是web系统，用于完成不同的业务功能，处于中间的是服务中心，不同的服务中心提供不同的业务服务，处于最下层的则是业务的数据库

	与之前相比有几个重要的变化，首先业务功能之间的访问不仅仅是单机内部的方法调用，还引入了 远程的服务调用。其次，共享代码不再是散落在不同的应用中，这些实现被放在各个服务中心。最 后，数据库的连接也发生了一些变化，我们把数据库的交互工作放到了服务中心，让前端的 web 应 用更加注重与浏览器的交互工作，而不必过多关注业务逻辑的事情。链接数据库的任务交给响应的 业务服务中心了，这样可以降低数据库的连接数。 而服务中心不仅把一些可以共用的代码集中管理，而且还使得这些代码变得更好维护。 服务化的方式会带来很多好处，首先，从结构上来看，系统架构更加清晰了，比原本的架构 更加立体。从稳定性上来看，一些散落在多个应用系统中的代码变成了服务并且由专门的团队进行统一维护，一方面可以提高代码的质量，另一方面由于基础核心模块相对稳定，修改 和发布的频次相对于业务系统来说会少很多，这也会提高整个架构的稳定性。最后，更加底 层的资源由服务层统一管理，结构更加清晰，对于团队开发效率来说有比较大的提高 服务化的方式，对于研发也会有很大的影响，以前的开发模式是几个大团队负责几个大应用， 随着服务化的落地，我们的应用数量会飞速增长，系统内部的依赖关系也会变的错综复杂， 同时团队也进行了拆分，每个小团队专注于某个具体的服务或者应用上，迭代效率也会更高。