微服务架构一

• 基本概念
• 架构的发展过程

对于微服务来说，分布式架构将是研究的重点，本篇介绍分布式架构的一些概念！

基本概念

• 冯诺依曼模型

• “去 IOE”运动

IOE 指的是 IBM 小型机、Oracle 数据库、EMC 的高端存储

• 分布式系统的意义

  1.升级单机处理能力的性价比越来越低

单机的处理能力主要依靠 CPU、内存、磁盘。通过更换硬件 做垂直扩展的方式来提升性能，成本会越来越高。

2.单机处理能力存在瓶颈

单机处理能力存在瓶颈，CPU、内存都会有自己的性能瓶颈， 也就是说就算你是土豪不惜成本去提升硬件，但是硬件的发 展速度和性能是有限制的。

3.稳定性和可用性这两个指标很难达到

单机系统存在可用性和稳定性的问题，这两个指标又是我们 必须要去解决的

• 分布式常用概念

  1. 集群（两个厨子比一个厨子做饭做的多）

  2. 分布式 （把每个厨子的功能根据任务拆分成若干功能，每个子功能一个服务节点，整个流程统称分布式）

  3. 节点（节点是指一个可以独立按照分布式协议完成一组逻辑的程序个体）

• 副本机制

  副本(replica/copy)指在分布式系统中为数据或服务提供的冗余。

  数据副本指在不同的节点上持久化同一份数据，当出现某一个 节点的数据丢失时，可以从副本上读取到数据。数据副本是分 布式系统中解决数据丢失问题的唯一手段。 服务副本表示多个节点提供相同的服务，通过主从关系来实现 服务的高可用方案

• 中间件

  中间件位于操作系统提供的服务之外，又不属于应用，他是位于应用和系统层之间为开发者方便的处理通信、输入输出的一类软件，能够让用户关心自己应用的部分

• CAP原则

CAP原则又称CAP定理，指的是在一个分布式系统中，Consistency（一致性）、 Availability（可用性）、Partition tolerance（分区容错性），三者不可兼得。Consistency（一致性）。 Availability（可用性）。Partition tolerance（分区容错性）

总结一下：CAP 并不是一个普适性原理和指导思想，它仅 适用于原子读写的 NoSql 场景中，并不适用于数据库系统。

• base原则

Basically Available（基本可用）、Soft state（软状态）和Eventually consistent（最终一致性）三个短语的简写；

BASE是对CAP中一致性和可用性权衡的结果，其来源于大规模互联网系统分布式实践的总结，是基于CAP定理逐步演化而来的，其核心思想是即使无法做到强一致性（Strong consistency），但每个应用都可以根据自身的业务特点，采用适当的方式来使系统达到最终一致性（Eventual consistency）。接下来我们着重对BASE中的三要素进行详细讲解。

基本可用

基本可用是指分布式系统在出现不可预知的故障的时候，允许损失部分可用性——但请注意，这绝不等价于系统不可用。以下两个就是“基本可用”的典型例子。 响应时间上的损失：正常情况下，一个在线搜索引擎需要在0.5秒之内返回给用户相应的查询结果，但由于出现故障（比如系统部分机房发生断点或断网故障），查询结果的响应时间增加1~2秒。 功能上的损失：正常情况下，在一个电子商务网站上进行购物，消费者几乎能够顺利地完成每一笔订单，但是在一些节目大促购物高峰的时候，由于消费者的购物行为激增，为了保护购物系统的稳定性，部分消费者可能会被引导到一个降级页面。

弱状态

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

最终一致性

最终一致性 最终一致性强调的是系统中所有的数据副本，在经过一段时间的同步后，最终能够达到一个一致的状态。 在实际工程实践中，最终一致性存在以下五类主要变种。 因果一致性（Causal consistency） 因果一致性是指，如果进程A在更新完某个数据项后通知了进程B，那么进程B之后对该数据项的访问都应该能够获取到进程A更新后的最新值，并且如果进程B要对该数据项进行更新操作的话，务必基于进程A更新后的最新值，即不能发生丢失更新情况。与此同时，与进程A无因果关系的进程C的数据访问则没有这样的限制。 读己之所写（Read your writes） 读己之所写是指，进程A更新一个数据项之后，他自己总是能够访问到更新过的最新值，而不会看到旧值。 会话一致性（Session consistency） 会话一致性将对系统数据的访问过程框定在了一个会话当中：系统能保证在同一个有效地会话中实现“读己之所写”的一致性。 单调读一致性（Monotonic read consistency） 单调读一致性是指如果一个进程从系统中读取出一个数据项的某个值后，那么系统对于该进程后续的任何数据访问呢都不应该返回更旧的值。 单调写一致性（Monotonic write consistency） 单调写一致性是指，一个系统需要能够保证来自同一个进程的写操作被顺序的执行。

BASE 理论的核心思想是：即使无法做到强一致性，但每个 应用都可以根据自身业务特点，采用适当的方式来使系统 达到最终一致性

架构的发展过程

一个成熟的大型网站系统架构并不是一开始就设计的非常完美，也不是一开始就具备高性能、高可用、安全性等特性，而是随着用户量的增加、业务功能的扩展逐步完善演变过来的。在这个过程中，开发模式、技术架构等都会发生非常大的变化。而针对不同业务特征的系统，会有各自的侧重点，比如像淘宝这类的网站，要解决的是海量商品搜索、下单、支付等问题；像腾讯，要解决的是数亿级别用户的实时消息传输；百度所要 解决的是海量数据的搜索。每一个种类的业务都有自己不同的系统架构。我们简单模拟一个架构演变过程。

我们以 javaweb 为例，来搭建一个简单的电商系统，从这个系统中来看系统的演变历史；要注意的是，接下来的演示模型，关注的是数据量、访问量提升，网站结构发生的变化， 而不是具体关注业务功能点。其次，这个过程是为了让大家更好的了解网站演进过程中的一些问题和应对策。

假如我们系统具备以下功能：

用户模块：用户注册和管理 商品模块：商品展示和管理 交易模块：创建交易及支付结算

阶段一，单应用架构

网站的初期也可以认为是互联网发展的早起，我们经常会在单机上跑我们所有的程序和软件。把所有软件和应用都部署在一台机器上，这样就完成一个简单系统的搭建，这个时候的讲究的是效率。

阶段二，应用服务器和数据库服务器分离

随着网站的上线，访问量逐步上升，服务器的负载慢慢提高，在服务器还没有超载的时候，我们应该做好规划，提升网站的负载能力。假如代码层面的优化已经没办法继续提高，在不提高单台机器的性能，增加机器是一个比较好的方式，投入产出比非常高。这个阶段增加机器的主要目的是讲 web 服务器和数据库服务器拆分，这样不仅提高了单机的负载能力，也提高了容灾能力。

阶段三，应用服务器集群-应用服务器负载告警，如何让应用服务器走向集群

随着访问量的继续增加，单台应用服务器已经无法满足需求。在假设数据库服务器还没有遇到性能问题的时候，我们可以增加应用服务器，通过应用服务器集群将用户请求分流到各个服务器中，从而继续提升负载能力。此时多台应用服务器之间没有直接的交互，他们都是依赖数据库各自对外提供服务；

架构发展到这个阶段，各种问题也会慢慢呈现

1. 用户请求由谁来转发到具体的应用服务器
2. 用户如果每次访问到的服务器不一样，那么如何维护session

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

架构演变到这里，并不是终点。上面我们把应用层的性能拉上来了，但是数据库的负载也在慢慢增大，那么怎么去提高数据库层面的负载呢？有了前面的思路以后，自然会想到增加服务器。但是假如我们单纯的把数据库一分为二，然后对于后续数据库的请求，分别负载到两台数据库服务器上，那么一定会造成数据库不统一的问题。所以我们一般先考虑读写分离的方式；

这个架构的变化会带来几个问题

1. 主从数据库之间的数据同步 ； 可以使用 mysql 自带的 master-slave 方式实现主从复制
2. 对应数据源的选择 ； 采用第三方数据库中间件，例如 mycat

阶段五 使用搜索引擎缓解读库的

数据库做读库的话，尝尝对模糊查找效率不是特别好，像电商类的网站，搜索是非常核心的功能，即便是做了读写分离，这个问题也不能有效解决。那么这个时候就需要引入搜索引擎了使用搜索引擎能够大大提高我们的查询速度，但是同时也会带来一些附加的问题，比如维护索引的构建。

阶段六，引入缓存机制缓解数据库的压力

随着访问量的持续增加，逐渐出现许多用户访问统一部分内容的情况，对于这些热点数据，没必要每次都从数据库去读取，我们可以使用缓存技术，比如 memcache、redis 来作为我们应用层的缓存；另外在某些场景下，比如我们对用户的某些IP的访问频率做限制，那这个放内存中又不合适，放数据库又太麻烦，这个时候可以使用Nosql 的方式比如 mongDB 来代替传统的关系型数据库；