互联网海量分布式架构演进之路

一.互联网发展三阶段

1.2007年之前，PC互联网(PC Internet)，让数据可以在一定范围内在线化

互动形式：互动1.0（门户）

　　内容在线

　　但互动方式没有变化

　　还是一个中心对多点广播模式

　　三大门户

2.2007-2013年，移动互联网(Mobile Internet)，让人越来越多的数据被记录被联通，让数据智能成为可能，iPhone 4上市里程碑

互动形式：互动2.0（搜索互动）

　　以互动为核心

　　产品有了“关注”，因为“关注”互动产生了网络效应，说的人越多，看的人越多，反之亦然，这就是网络效应，让网络因为“关注”这个机制有了自成长的可能性

　　微博、twitter、instagram

3.2013-二维码，物联网(Internet Of Things)，让网络协同从人扩展到万物

互动形式：互联3.0（SNS网络）

　　群组和朋友圈

　　把“关注”的一对一的关系，变成了更广泛的多对多的关系，形成了真正的交互网络形态，人和信息都在线了，网越织越密，才能用更高效的方式实现原来很难实现的事

　　微信、facebook

4.互联网发展特点

　　业务功能越来越多、越来越复杂

　　万物互联数据量越来越大

　　请求量越来越大，更高的用户体验要求

　　业务快速迭代，持续交付的能力

 

二.互联网架构演进之路

　　Monoliths：单体架构，all in one，所有的功能都在同一个工程里实现，在一个tomcat里提供服务。随着业务发展，一个单体不太行了，数据库的思路，最开始是单库单表，随着请求量增加，为解决性能问题。无非做两个拆分，第一个拆分就是按业务功能垂直拆分，按业务把单库分成十个数据库。如分库后里面的数量还很大，就需进一步做水平拆分，那就是拆表，如按userid取模分表。在架构层面，思路也是一样，也是按垂直和水平两个思路来拆分。

　　Horizontal layered：水平分层架构，按水平方向拆分

　　SOA：面向服务架构，按垂直方向拆分

　　MicroService：微服务架构，既按水平方向拆分，也按垂直方向拆分

　　Service Mesh：服务网格架构，是微服务架构的2.0时代

 

三.单体架构

1.什么是单体架构

电商系统案例：

　　e-commerce application

　　It takes orders from customers,verifiers inventory and available credit,and ships them.

Monoliths：

　　a single Java WAR file

　　a single directory hierarchy of Java code.

　　账户服务、库存服务、运输服务、交互层面的UI等所有功能打了一个war包，部署到Tomcat容器里。

2.单体架构优点

　　部署简单、容易测试、开发初期容易、扩展性也非常好

3.Monoliths适用场景

　　业务场景简单、功能不复杂、研发人员较少，比如：O2O

　　创业公司初期（技术不那么重要，生存下来最重要）

　　性能要求极期苛刻（金融里面有一个高频交易，如股价有波动时，要及时捕捉到）

4.Monoliths缺点

　　系统耦合性高

　　技术选型单一

　　开发效率越来越低下

5.如何破局

　　数据库存储量大破局思路

　　拆分（垂直拆分、水平拆分）

　　架构同样适用（垂直方向拆分、水平方向拆分）

 

四.水平分层架构

1.什么是水平分层架构

对应数据库的水平分表

案例：

　　e-commerce application

　　It takes orders from customers,verifiers inventory and available credit,and ships them.

水平分层架构：

　　水平方向物理分成多个独立进程（网关层、业务逻辑层、数据访问层、数据存储层）

　　每层逻辑解耦

　　分成几层，第一层是网关层，网关层就是一个独立的进程，业务逻辑层就做业务逻辑，如账户服务、库存服务、运输服务，数据访问层是和数据打交道的。由原来在单体架构中的一个进程分成了多个进程，每一层是逻辑解耦的。

2.分层设计原则

　　数据服务和逻辑服务分离

　　逻辑服务和网关服务分离

　　网关服务和展示服务分离（如国际化的电商业务，时间交给展示层处理）

3.网关层功能

　　功能一：请求鉴权，如对发布商品鉴权，要是登录态

　　功能二：数据完整性检查，只做完整性检查，不检查具体语义

　　功能三：协议转换，nginx到网关是https或http，数据协议是json，但网关和业务逻辑层的通信协议可以是json、二进制、protobuf、rpc，数据协议可以是json、protobuf等，在我不需要理解语义的情况下，如何做协议转换，如将json转换成protobuf

　　功能四：路由转发

　　功能五：服务治理（限流、熔断等）

4.业务逻辑层

　　功能一：业务逻辑判断

　　案例：微信黑名单检查、微信好友删除、微信发消息不重不漏

5.数据访问层

　　功能一：CRUD

　　功能二：ORM(mybatis等)

　　功能三：sharding(分库分表对上层不可见，如Sharding jdbc)

　　功能四：屏蔽底层存储差异性

　　案例：技术升级newSQL。如TiDB，不管你数据量有多大（如1000亿），你使用时就当它是一张单表（当然，没有表关联）

　　缓存大家用什么？redis，redis集群模式有一定的问题，当做一些批量查询时支持的不好，codis支持的比较好，本身是集群，但底层也是主从模式。

6.同步架构

　　同步架构或异步架构？同步架构，但在很多情况下，我们需要异步架构的，那就是同步转异步。

　　异步一般用MQ，一般回在网关屋和业务逻辑层之间。

　　异步目的：提升吞吐量

　　异步手段：消息队列

　　适用场景：请求类型、业务类型。读请求不能用异步，查询不能用异步，写可以用异步。

7.层次划分

　　层次划分不能太多，也不能过少。

　　过多会导致请求路径变长、平均响应延迟变高、定位问题变的复杂化、运维成本增加

　　过少又变回单体架构了

　　适中：

　　四层（同步架构）：网关层、业务逻辑层、数据访问层、数据存储层

　　五层（异步架构）：网关层、异步消息队列层、业务逻辑层、数据访问层、数据存储层

8.水平分层架构设计的缺点

‘　　每层粒度过粗（业务逻辑层只是逻辑上做了分层，实际上还是一个服务）

 

五.面向服务架构

1.SOA定义

　　组件模型

　　不同功能单元（服务）通过定义的良好接口关联

　　接口采用中立的方式定义，独立于硬件平台、操作系统和编程语言

2.SOA提出

　　1996年提出

　　不同认知和理解

　　2000年逐步落地（ESB、WebService、SOAP等等）

3.什么是SOA架构？

　　多个独立服务，不同业务不同的服务，做了垂直拆分

　　通过ESB交互

4.SOA缺点

　　每个服务还是Monoliths

　　对ESB严重依赖

 

六.微服务架构

1.微服务如何拆分

        对一般的业务系统，可以按功能单元垂直拆分，如二手交易平台拆分成用户、商品、搜索、推荐、交易这些微服务，但对于特殊的，如商品还可以按拆分成商品读微服务、商品写微服务两个微服务，即按API进一步拆分。但对于用户、商品、搜索、推荐、交易这些还是单体，单体还可以拆分，即每个单体再进行水平方向的拆分，如进一步拆分成App、网关层（当然，网关是无状态的，是共用的）、业务逻辑层、数据访问层、DB/Cache层。

        网关有用springBoot做，当然用SpringCloud也可以。

        微服务架构是James Lewis和Martin Fowler提出的。

        什么是微服务架构？

        a.a suite of small services一系列小的服务

        b.running in its own process每个进程可以独立运行

        c.around business capabilities围绕业务建模的能力，即按照业务单元的垂直拆分

        d.independently deployable独立部署

        e.bare minimum of centralized management弱中心化的管理（去中心化的管理）

        去中心化的管理即每个微服务可以用不同的语言来写，DB也可以用不同的数据库，当然实际上很少用不同的语言写，假设网关用JAVA，业务逻辑层用C++，网关和业务逻辑层通讯用的是Dubbo，这里网关就需要一套java的dubbo客户端，如果数据访问层用的是Go语言，那么业务逻辑层就又需要一套C++的dubbo客户端。这样的话，一旦用了多语言，通讯基础设施就变得非常重要，针对每一个语言都要写一层通信基础设施的话，这个问题就变得非常非常复杂，这个通信不仅是包括建立连接、传输数据，还包括负载匀衡、熔断、路由、服务降级、服务注册、服务发现这些东西，每种语言都写一套，自然就相当复杂了，就把自已搞死了。这就是为什么微服务架构推出2.0的原因，微服务2.0其实就是Service Mesh，Service Mesh就是解决各层的通信问题，它希望把通信的基础设施从你的网关、业务逻辑层、数据访问层剥离出来，那么你就不用去关心通信设施了。当然，如果在微服务1.0阶段，如果你解决不好通信的问题，那多语言就是一个摆设。实施微服务的初期，大部分公司用的都是同一种语言，这样各层的通信框架只需要一套就好了。

        所以在微服务1.0阶段，语言用一种就好了，数据库用同一种也差不多了。这样就不用考虑这么多的异构的问题。

        电商APP案例：有用户、库存、账号、邮寄的服务，客户端有移动的和PC的，它针对每一种终端有一个GateWay，接下来是具体的服务，每一个服务有自已的DB。

        二手交易平台微服务架构：

        在这里，注册中心是基于Zookeeper来做的，配置中心是基于Apollo（携程开源的）来做的。严格来说，小规模集群用的是zk，大规模集群用的不是zk，zk是CP模型，大规模集群要用AP模型。zk是CP模型，当接入节点比较大以后，它们的数据一致性要求很高，ZK内部会同步很多数据，就把整个集群就拖跨了。

        CP模型：etcd、zk、cosoul

        AP模型：eruka

        注册中心用zk来做，实现简单功能是OK的，但是zk做配置中心会存在很多很多问题，授权、长连接、可视化管理界面这些东西会有很多问题。

        本质：就是按二个维度去拆分，一个是业务架构，另一个是组织架构。

        按业务功能的垂直拆分，另一个就是水平方向的拆分。微服务架构更多是一个业务架构，真正比较难是 按业务功能的垂直拆分，本质上是一个业务问题，懂业务、架构水平高的架构师比较值钱，脱离业务谈架构都是耍流氓。

        微服务架构其实是一个业务架构，系统架构其实算不上。另外，它也是一个组织架构，任何公司组织架构两种形式：按职能划分，比如产品中心、研发中心，另一种就是按业务划分，如房产中心、二手中心。按业务划分会好些，因为大家目标一致。这种情况下，实施微服务架构实施会好些。所以，微服务架构它不仅是一个业务架构，它还是一个组织架构。

2.微服务架构应用场合

1).目的

        a.项目快速迭代

        b.项目持续交付

2).适用场景

        a.不适合场景

        需求层面：半年迭代一次，频率太低没必要，如OA、EPR、考勤、工单系统、打卡系统，一旦上线后，后续变化很低，从需求层面没必要用微服务架构。

        性能层面：性能相对单体架构是变快了还是变慢了呢？一个是吞吐量相对单体架构一定是变大了，但平均响应时间一定是变低了，因为原来单体进来以后在一个模块里就完成了，而微服务架构里面，从网关经过一次网络交互到业务逻辑层，业务逻辑层又要经过一次网络交互到数据访问层，特别是跨机房的，平均响应时间就变低了。如果有些系统对平均响应时间要求是非常非常高的，高到1毫秒都不能接受，如量化交易、高频交易（即时捕捉到股票上涨趋势，这个趋势第一时间要捕捉到，如用户捕捉到涨了一毛钱，就要把手上的股票卖出去，如果你捕捉到的时间比别人慢，有可能价格就降下来了，就亏了，所以在这种情况下用微服务架构是不OK的），但互联网、金融行业的大多数应用，可没有这么高的要求。

        c.数据一致性层面

        强一致性：任何人、任何时间、任何地点访问任何服务得到的数据都是完全一致的。

        最终一致性：任何人、任何时间、任何地点访问任何服务得到的数据延迟一会，如毫秒级、秒级延迟

        在微服务架构里，

        b.适合场景：

        需求层面：一周一次、两周一次

3.微服务典型架构模式

 

4.微服务如何达到99.999%的高可用

 

5.微服务真实案例篇

 

 

七.架构案例实践

 

特别说明：《开课吧》公开课的学习笔记