互联网总体架构设计篇

小鱼儿 2021-12-16 09:01 356阅读 0赞

### 文章目录 ###

*  序言
 *  01 互联网发展三阶段
 *  02 互联网架构演进之路
 *  03 单体架构设计与实践
 *  04 水平分层架构设计与实践
 *  05 面向服务架构设计与实践
 *  06 微服务架构设计与实践
 *  07 服务网格架构设计与实践
 *  08 千亿级互联网案例实践

# 序言 #

架构是用来唤醒智慧的，期望唤醒和您心中的架构共鸣，今年您在观察什么，希望我们英雄所见略同，有不同的看法欢迎评论留言，如果只是单单因为观点不同就被骂的狗血喷头，这可真是太过幼稚，现在的人太过浮躁，何必呢，有什么事是不能坐下来好好谈谈的？来，给您倒一杯卡布奇诺，咱们慢慢品。

# 01 互联网发展三阶段 #

互联网发展的三个阶段的特点依次是静态化、动态化、万物连接，容易理解，在其发展过程中，互动形式也发生了三个阶段的演进。  
  微信和facebook最主要的发明就是群组和朋友圈，但实际上朋友圈不算微信的发明，微博在2.0阶段的feed流就已经做出了朋友圈的雏形。微信最厉害的地方就是群组，把关注的一对一关系，变成了多对多关系，互联网在发展过程中，也形成了以下特点：

*  业务功能越来越多、越来越复杂
 *  万物互联、数据量越来越大
 *  请求量越来越大、更高的用户体验要求
 *  业务快速迭代、持续交付的能力

做架构的目的不是为了炫技，为了让我们的产品快速迭代，持续交付，降低人力成本，机器成本，提升开发效率，提升运营效率。互联网架构为什么要演进？很显然，**需求驱动架构演进**。  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly94dWNoZW4uYmxvZy5jc2RuLm5ldA_size_16_color_FFFFFF_t_70]  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly94dWNoZW4uYmxvZy5jc2RuLm5ldA_size_16_color_FFFFFF_t_70 1]

# 02 互联网架构演进之路 #

![互联网架构演进][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly94dWNoZW4uYmxvZy5jc2RuLm5ldA_size_16_color_FFFFFF_t_70 2]  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly94dWNoZW4uYmxvZy5jc2RuLm5ldA_size_16_color_FFFFFF_t_70 3]

# 03 单体架构设计与实践 #

单体架构适用场景：

*  业务简单，功能不复杂，研发人员较少
 *  创业公司初期
 *  性能要求极其苛刻

单体架构的优点：

*  容易开发
 *  容易测试
 *  容易部署
 *  容易扩展

单体架构的缺点：

*  系统耦合性高
 *  技术选型单一
 *  开发效率越来越低下

架构破局：

*  垂直方向拆分（业务维度）例如用户模块，订单模块，商品模块。
 *  水平方向拆分（功能维度）垂直拆分后，用户模块依然是一个单体，在功能上继续拆分，网关层，业务逻辑层，数据访问层，数据库怎么拆，架构就怎么拆。

# 04 水平分层架构设计与实践 #

水平方向物理分为多个进程，每层逻辑解耦

*  网关层
 *  业务逻辑层
 *  数据访问层
 *  数据存储层

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly94dWNoZW4uYmxvZy5jc2RuLm5ldA_size_16_color_FFFFFF_t_70 4]  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly94dWNoZW4uYmxvZy5jc2RuLm5ldA_size_16_color_FFFFFF_t_70 5]  
  任意两层之间加入消息队列都可以从同步变为异步，每层和消息队列都是同步的。消息队列的高效来源于本身的顺序写入。![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly94dWNoZW4uYmxvZy5jc2RuLm5ldA_size_16_color_FFFFFF_t_70 6]  
  业界主流的网关开源组件，没有最好，只有更合适。  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly94dWNoZW4uYmxvZy5jc2RuLm5ldA_size_16_color_FFFFFF_t_70 7]  
  同步架构  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly94dWNoZW4uYmxvZy5jc2RuLm5ldA_size_16_color_FFFFFF_t_70 8]  
  异步架构  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly94dWNoZW4uYmxvZy5jc2RuLm5ldA_size_16_color_FFFFFF_t_70 9]

*  异步目的：提升吞吐量
 *  异步方式：消息队列
 *  适用场景一：请求类型（读请求不可以，写请求可以）
 *  适用场景二：业务类型（充值场景低并发用同步，社交场景高并发用异步）

不是所有的请求都可以用MQ,读请求不能用MQ， 因为读请求是想要拿到这次请求的结果，比如说要查询一个用户的信息，瞬时要拿到用户的结果，这个请求通过网关到MQ,返回ok，难道这个用户就叫ok吗？写请求是可以用MQ的，所有的写请求都能用MQ吗？那又回到哲学本质了，所有的所有的一切都是不成立的。不是所有的写请求都可以用MQ的。写请求分两种，一种是对数据一致性强，比如充值场景。这个时候就不能用异步了，用同步架构就好了，一种是对数据一致性弱，比如社交场景可以写异步。也可以从业务的并发量来考虑，并发量低的用同步，并发量高的用异步。  
  但是异步架构发生在写入请求后，我在读请求的时候MQ的消息还没有到DB,但是在写入的时候，已经告诉用户已经成功了，这个问题我们回到具体的业务场景。  
  在我们发朋友圈的时候，很显然自己对马上要发的朋友圈最感兴趣，你绝对不会说，在发朋友圈之前，在群里去@大家说：我要发朋友圈了，你们来看一下，我相信你一定不会干这个事情，既然你不会干这个事情，你的朋友晚点看到朋友圈也是ok的，那这个时候只要解决自己看的问题就好了，这个时候只需要把本地发送的消息（朋友圈）客户端缓存一下，等到你下次再请求的时候，已经是很多秒以后的事情了，下次再请求的时候，写入的消息已经到DB了，用这种方式来解决用户看到有延迟的问题。但是这样也存在问题，虽然说这次可以骗过用户，但是消息是写到MQ里面的，最终是要把它写入到DB里面去的，但是从MQ到DB过程中，会出现网络异常，消息不合法等，最终消息是没法写入到DB里面去的。  
  微信是这样做的，当微信消息（朋友圈）发成功以后，过一段时间如果没有发成功，会在最顶端提示您有一条消息未发送成功，让你重试一下 ，这是依靠微信app和网关的Socket长链接来实现的，一旦业务逻辑层处理失败后，会直接推给客户端，如果http没办法处理，那必须是长轮询来处理。

异步架构会有一些负面的影响：

*  请求路径边长
 *  平均响应延迟变高
 *  定位问题变的复杂化
 *  运维成本增加

最终我们在实际应用中，同步架构分为四层，异步架构分为五层最合适，MVC这种架构已经逐渐的被淘汰了，在水平分层上选择四层或者5层架构。  
![架构分层][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly94dWNoZW4uYmxvZy5jc2RuLm5ldA_size_16_color_FFFFFF_t_70 10]  
  以上两种架构也存在严重的问题：部分层粒度过粗，如业务逻辑层包含了所有的业务逻辑。

**同步水平分层全貌**  
  真正的APP请求第一步是经过DNS的，DNS通过域名获IP，去请求静态接口和动态接口的数据。静态的资源如CSS、图片是放在CDN上的，通过阿里、腾讯、百度的CDN获取静态图片，如果请求的静态资源在CDN上没有命中，CDN会请求Nginx，Nginx会把静态资源返回给CDN，CDN会把静态资源缓存起来再返回给APP，Object Store（对象存储）同理，常用的对象存储是阿里的Fastdfs和Ceph，规模比较小的话建议用Fastdfs，规模比较大的话，建议用Ceph，但是Ceph会给运维团队增加很大的压力，  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly94dWNoZW4uYmxvZy5jc2RuLm5ldA_size_16_color_FFFFFF_t_70 11]

# 05 面向服务架构设计与实践 #

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly94dWNoZW4uYmxvZy5jc2RuLm5ldA_size_16_color_FFFFFF_t_70 12]  
  58同城的简化模型图：  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly94dWNoZW4uYmxvZy5jc2RuLm5ldA_size_16_color_FFFFFF_t_70 13]  
  为什么SOA不是微服务架构，因为它仅仅做了一个垂直拆分。所以缺点也很明显：

*  每个服务还是单体架构
 *  对ESB严重依赖

# 06 微服务架构设计与实践 #

微服务架构即按照水平方向去拆分，又按照垂直方向去拆分

# 07 服务网格架构设计与实践 #

# 08 千亿级互联网案例实践 #

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly94dWNoZW4uYmxvZy5jc2RuLm5ldA_size_16_color_FFFFFF_t_70]: /images/20211214/35060d277c5f4313923bef96849d3eb1.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly94dWNoZW4uYmxvZy5jc2RuLm5ldA_size_16_color_FFFFFF_t_70 1]: /images/20211214/36edb76e5e214b3d9dea1932447171bc.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly94dWNoZW4uYmxvZy5jc2RuLm5ldA_size_16_color_FFFFFF_t_70 2]: /images/20211214/844436c5a6664e7e95064c4c7d8d860d.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly94dWNoZW4uYmxvZy5jc2RuLm5ldA_size_16_color_FFFFFF_t_70 3]: /images/20211214/f12ac928dd7b442d88a14646d2f697f8.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly94dWNoZW4uYmxvZy5jc2RuLm5ldA_size_16_color_FFFFFF_t_70 4]: /images/20211214/2f3e11d7b579429e88eaadcca6f9c248.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly94dWNoZW4uYmxvZy5jc2RuLm5ldA_size_16_color_FFFFFF_t_70 5]: /images/20211214/fbd514c0bcc040218c5d2d83d1a237a4.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly94dWNoZW4uYmxvZy5jc2RuLm5ldA_size_16_color_FFFFFF_t_70 6]: /images/20211214/86c376a70ad342aead7a7528650a8665.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly94dWNoZW4uYmxvZy5jc2RuLm5ldA_size_16_color_FFFFFF_t_70 7]: /images/20211214/8718c76765894c1aa40278d7d481db66.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly94dWNoZW4uYmxvZy5jc2RuLm5ldA_size_16_color_FFFFFF_t_70 8]: /images/20211214/5424440468444ffe85d7d75f72e2ced8.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly94dWNoZW4uYmxvZy5jc2RuLm5ldA_size_16_color_FFFFFF_t_70 9]: /images/20211214/62e0df7971434be5967ad0a9f4920906.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly94dWNoZW4uYmxvZy5jc2RuLm5ldA_size_16_color_FFFFFF_t_70 10]: /images/20211214/0900d219b9014e1c936a00c7fd4d670b.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly94dWNoZW4uYmxvZy5jc2RuLm5ldA_size_16_color_FFFFFF_t_70 11]: /images/20211214/953a5fc0a66c4f509eb9d3be8e8dc984.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly94dWNoZW4uYmxvZy5jc2RuLm5ldA_size_16_color_FFFFFF_t_70 12]: /images/20211214/ba5e7d020e94412cbbcd4d08e276777f.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly94dWNoZW4uYmxvZy5jc2RuLm5ldA_size_16_color_FFFFFF_t_70 13]: /images/20211214/6988b863ab0c4822b2121a4679414e40.png