随着互联网的发展，网站应用的规模不断扩大。需求的激增，带来的是技术上的压力。系统架构也因此不断的演进、升级、迭代。从单一应用，到垂直拆分，到分布式服务，到SOA，以及现在火热的微服务架构，还有在Google带领下来势汹涌的Service Mesh。我们到底是该乘坐微服务的船只驶向远方，还是偏安一隅得过且过？

集中式架构

当网站流量很小时，只需一个应用，将所有功能都部署在一起，以减少部署节点和成本。此时，用于简化增删改查工作量的数据访问框架(ORM)是影响项目开发的关键。
存在的问题：

  • 代码耦合，开发维护困难
  • 无法针对不同模块进行针对性优化
  • 无法水平扩展
  • 单点容错率低，并发能力差

    架构1.0

    image.png
    所有的交互都是单向的，也就是，从服务器请求到的资源都以静态资源展示给用户

    架构2.0

    image.png
    比1.0多了一个数据库模块，此时用户就可以对资源进行增删查改，所有对资源的操作都会存储到数据库(DB)中，该架构所展示的页面，我们通常叫做动态页面。

    架构3.0 集中式架构

    image.png
    此阶段已经到了单体服务阶段了，该阶段用户访问量不大，由此演变了一个MVC架构模型。随着用户量越来越多，用户产生的数据也越来越多，如果单体服务宕机后，所有的服务均不能访问，因此服务器性能不能满足项目的需求。

    架构4.0 集中式架构

    image.png

为了解决架构3.0的问题，我们将文件服务器和数据库给分离出来。

架构5.0 集中式架构

image.png
比如我们现在玩的单机游戏，往往都容量都非常大（几十G，乃至上百G），轻轻松松都超过了电脑内存（16G）。那么很明显电脑在运行游戏时，是不可能将整个游戏文件都放入内存的。但是如果文件都在硬盘里，需要的时候再读取，显然硬盘的读写速度时不够的（由于游戏文件类别很多，所以硬盘不可能一直顺序读写），那游戏也会经常卡顿，加载缓慢等。那么该如何解决这个问题呢？
其实这个问题和我们业务中遇到的一些问题是很类似的。一方面我们希望用户可以在保证用户体验的前提下查询数据（如设备列表，订单列表等），另一方面我们不可能将所有数据都放在内存（内存的读写速度比硬盘快，所以就不解释为什么用硬盘了）中。那么到底该怎么解决这个问题呢？
这里就需要说到局部性原理了。局部性原理指的是数据的访问往往趋向于聚集在较小的连续区域。这里的连续区域包含两个方面：
时间维度：一个被使用的数据，在接下来较短的时间内，往往会被再次使用。
空间维度：一个被使用的数据，其关联的数据，往往也会被使用。
局部性原理是在内存，高速缓存部分，提出来用于解决问题的。

架构6.0

image.png
架构集群到读写分离，虽然说能够抗住一定的数据库单节点压力，但当数据量达到一定量级后（700万以上），数据库的查询和插入性能会下降。因此需要数据库集群和分库分表。也就是同一张表的数据，会根据一定的算法散列在不同的节点，这种做法叫分布式数据库。当使用这种模式后，数据库的主键就不能使用自增长，需要分布式主键来做，后面的文章中会详细介绍。
image.png

分布式服务

当垂直应用越来越多，应用之间交互不可避免，将核心业务抽取出来，作为独立的服务，逐渐形成稳定的服务中心，使前端应用能更快速的响应多变的市场需求。此时，用于提高业务复用及整合的分布式调用是关键。
image.png
优点：

  • 将基础服务进行了抽取，系统间相互调用，提高了代码复用和开发效率

缺点：

  • 系统间耦合度变高，调用关系错综复杂，难以维护

    流动计算架构（SOA）

    SOA ：面向服务的架构
    当服务越来越多，容量的评估，小服务资源的浪费等问题逐渐显现，此时需增加一个调度中心基于访问压力实时管理集群容量，提高集群利用率。此时，用于提高机器利用率的资源调度和治理中心(SOA)是关键。
    1525530804753.png
    以前出现了什么问题？

  • 服务越来越多，需要管理每个服务的地址

  • 调用关系错综复杂，难以理清依赖关系
  • 服务过多，服务状态难以管理，无法根据服务情况动态管理

服务治理要做什么？

  • 服务注册中心，实现服务自动注册和发现，无需人为记录服务地址
  • 服务自动订阅，服务列表自动推送，服务调用透明化，无需关心依赖关系
  • 动态监控服务状态监控报告，人为控制服务状态

缺点：

  • 服务间会有依赖关系，一旦某个环节出错会影响较大

  • 服务关系复杂，运维、测试部署困难，不符合DevOps思想

    微服务

    前面说的SOA，英文翻译过来是面向服务。微服务，似乎也是服务，都是对系统进行拆分。因此两者非常容易混淆，但其实却有一些差别：
    微服务的特点：

  • 单一职责：微服务中每一个服务都对应唯一的业务能力，做到单一职责

  • 微：微服务的服务拆分粒度很小，例如一个用户管理就可以作为一个服务。每个服务虽小，但“五脏俱全”。
  • 面向服务：面向服务是说每个服务都要对外暴露Rest风格服务接口API。并不关心服务的技术实现，做到与平台和语言无关，也不限定用什么技术实现，只要提供Rest的接口即可。
  • 自治：自治是说服务间互相独立，互不干扰
    • 团队独立：每个服务都是一个独立的开发团队，人数不能过多。
    • 技术独立：因为是面向服务，提供Rest接口，使用什么技术没有别人干涉
    • 前后端分离：采用前后端分离开发，提供统一Rest接口，后端不用再为PC、移动段开发不同接口
    • 数据库分离：每个服务都使用自己的数据源
    • 部署独立，服务间虽然有调用，但要做到服务重启不影响其它服务。有利于持续集成和持续交付。每个服务都是独立的组件，可复用，可替换，降低耦合，易维护

微服务结构图：
1526860071166.png