互联网架构演进之路

    互联网产品常常面临庞大的用户量，日均数十亿PV的高并发，PB级别的数据存储等问题的挑战，同时要求保证系统的高可用和弹性伸缩，并且能够根据需要进行快速迭代扩展，这些都对于系统架构提出了很高的要求。

    互联网架构从简到繁的演进经历了单体架构-水平分层架构/SOA架构-微服务架构以及最新的service mesh的演进过程。如下图：

一、单体架构

    早期互联网产品用户量少，并发量低，数据量小，多数只需要单个应用服务器可以满足需要，而数据库和文件服务部署在外部单个服务器上，这就是最早互联网架构，架构图如下所示。

   

单体架构的优点是容易开发、部署和测试，其缺点是系统耦合性高、技术选型单一、开发效率低下。

随着用户规模和业务量的不断上涨，单个应用服务器将出现性能瓶颈，对于PB级的数据和高并发用户大流量访问，单一或者主备的数据库都已经不能满足需求。对于数据库存储量大破局思路是在垂直方向进行拆分即分库，水平方向进行拆分即分表。对于架构来说也是同理，可分为功能维度上即水平方向进行拆分和业务维度即垂直方向进行拆分。如下图所示：

二、水平分层架构

水平分层架构即从水平方向上进行拆分，如下图所示：

水平分层架构从水平方向物理分成多个独立的进程包含：

1.网关层

2.业务逻辑层

3.数据访问层

4.数据存储层

每层直接逻辑解耦

三、SOA架构

SOA架构即从垂直方向上进行拆分，如下图所示：

基于SOA的系统架构实现了松耦合，系统之间通过服务接口（Service API）和中心化管理的企业服务总线（ESB）进行交互, 每个服务从本质上还是单体服务，对ESB严重依赖。

四、微服务架构

微服务架构的定义如下：

    In short, the microservice architectural style  is an approach to developing a single application as a suite of small services, each running in its own process and communicating with lightweight mechanisms, often an HTTP resource API. These services are built around business capabilities and independently deployable by fully automated deployment machinery. There is a bare minimum of centralized management of these services, which may be written in different programming languages and use different data storage technologies.

  翻译如下：

简而言之，微服务架构风格[是一种将单应用程序作为一套小型服务开发的方法，每种应用程序都在其自己的进程中运行，并与轻量级机制（通常是HTTP资源的API）进行通信。这些服务是围绕业务功能构建的，可以通过全自动部署机制进行独立部署。这些服务的集中化管理已经是最少的，它们可以用不同的编程语言编写，并使用不同的数据存储技术。

微服务从本质上来说就是水平分层架构和垂直分层架构（SOA）的结合，如下图所示：

微服务架构适用于项目的快速迭代及持续交付。

但是微服务不是银弹,微服务架构下，每个单体服务需要解决以下问题：

四、服务网格架构

服务网格架构定义如下：

A service mesh is a dedicated infrastructure layer for handling service-to-service communication. It’s responsible for the reliable delivery of requests through the complex topology of services that comprise a modern, cloud native application. In practice, the service mesh is typically implemented as an array of lightweight network proxies that are deployed alongside application code, without the application needing to be aware. (But there are variations to this idea, as we’ll see.)

翻译如下：

Service Mesh 是一个基础设施层，用于处理服务间通信。云原生应用有着复杂的服务拓扑，Service Mesh 保证请求可以在这些拓扑中可靠地穿梭。在实际应用当中，Service Mesh 通常是由一系列轻量级的网络代理组成的，它们与应用程序部署在一起，但应用程序不需要知道它们的存在。

如果用一句话来解释什么是 Service Mesh，可以将它比作是应用程序或者说微服务间的 TCP/IP，负责服务之间的网络调用、限流、熔断和监控。对于编写应用程序来说一般无须关心 TCP/IP 这一层（比如通过 HTTP 协议的 RESTful 应用），同样使用 Service Mesh 也就无须关系服务之间的那些原来是通过应用程序或者其他框架实现的事情，比如 Spring Cloud、OSS，现在只要交给 Service Mesh 就可以了。

Service Mesh的部署模型，先看单个的，对于一个简单请求，作为请求发起者的客户端应用实例，会首先用简单方式将请求发送到本地的Service Mesh实例。这是两个独立进程，他们之间是远程调用。
Service Mesh会完成完整的服务间调用流程，如服务发现负载均衡，最后将请求发送给目标服务。这表现为Sidecar。

Sidecar这个词中文翻译为边车，或者车斗，也有一个乡土气息浓重的翻译叫做边三轮。Sidecar这个东西出现的时间挺长的，它在原有的客户端和服务端之间加多了一个代理。

如果有大量的服务，就会表现出来网格。图中左边绿色方格是应用，右边蓝色的方框是Service Mesh，蓝色之间的线条是表示服务之间的调用关系。Sidecar之间的连接就会形成一个网络，这个就是服务网格名字的由来。这个时候代理体现出来的就和前面的sidecar不一样了，形成网状。