2024年网络安全最新微服务架构的演变_微服务架构演进(1)，2024年最新经验分享

给大家的福利

零基础入门

对于从来没有接触过网络安全的同学，我们帮你准备了详细的学习成长路线图。可以说是最科学最系统的学习路线，大家跟着这个大的方向学习准没问题。

同时每个成长路线对应的板块都有配套的视频提供：

因篇幅有限，仅展示部分资料

网络安全面试题

绿盟护网行动

还有大家最喜欢的黑客技术

网络安全源码合集+工具包

所有资料共282G，朋友们如果有需要全套《网络安全入门+黑客进阶学习资源包》，可以扫描下方二维码领取（如遇扫码问题，可以在评论区留言领取哦）~

网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。

需要这份系统化资料的朋友，可以点击这里获取

一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！

文章目录

• • 1.1 系统架构的演变过程
    • • 1.1.1 单体应用架构
        • 1.1.2 垂直应用架构
        • 1.1.3 分布式架构
        • 1.1.4 SOA架构
        • 1.1.5 微服务架构
    • 1.2 微服务架构设计原则
    • • 1.2.1 AKF拆分原则
        • • 1.2.1.1 X轴扩展（水平复制）
            • 1.2.1.2 Y轴扩展（模块拆分）
            • 1.2.1.3 Z轴扩展（数据分区）
        • 1.2.2 前后端分离原则
        • 1.2.3 无状态服务
        • • 1.2.3.1 状态化请求
            • 1.2.3.2 无状态请求
            • 1.2.3.3 HTTP是无状态的
            • 1.2.3.4 无状态服务带来的好处
        • 1.2.4 Restful通信风格

1.1 系统架构的演变过程

随着互联网的不断发展，网站应用的规模不断扩大，系统架构也因此也不断的演进、升级、迭代。从互联网早期到现在，系统架构大体经历了下面几个过程：

• 1）单体应用架构
• 2）垂直应用架构
• 3）分布式架构
• 4）SOA架构
• 5）微服务架构

1.1.1 单体应用架构

单体应用架构也叫集中式架构，在单体应用架构中，系统将所有的功能包括前端、后端等全部打包在一起部署，所有的代码都写在一起，通常也是交由一个小的技术团队开发；

优点：

• 项目架构简单，开发成本低
• 项目部署在一个节点上， 维护方便

缺点：

• 代码耦合度太高，开发维护困难
• 无法针对不同模块进行针对性优化
• 系统容错率低，如果该系统一个模块出现不可用会导致整个系统无法使用。

1.1.2 垂直应用架构

当访问量逐渐增大，单一应用无法满足需求，我们就需要增加节点来提供系统的访问能力，但是并不是所有的模块都需要进行性能的提高，这时候单体应用架构无法满足我们的需求；

我们需要将系统里面的模块进行拆分，这样对于后面的水平扩容是非常友好的；

优点：

• 系统拆分实现了流量分担，提高了系统并发量
• 垂直架构中可以针对不同模块进行针对性优化
• 方便水平扩展，负载均衡，系统容错率提高

缺点：

• 系统间相互独立，会有很多重复开发工作，影响开发效率
• 系统间相互独立，无法进行系统数据共享（互相调用）

1.1.3 分布式架构

当垂直应用越来越多，重复的业务代码就会越来越多，并且在垂直架构中应用之间的交互不可避免，此时，为了解决基础代码重复太多、应用之间的调用等问题；我们将重复的代码抽取出来作为独立的服务，对外提供服务；

优点：

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

缺点：

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

1.1.4 SOA架构

在分布式架构下，当服务越来越多，容量的评估，小服务资源等浪费等问题逐渐显现，此时需增加一个调度中心对集群进行实时管理集群容量

服务治理要做什么？（优点）

• 服务注册中心，实现服务自动注册和发现，无需人为记录服务地址
• 动态监控服务状态监控报告，人为控制服务状态
• 服务负载均衡、服务熔断保护、服务健康检测、服务注册与发现、服务缓存等…

缺点：

• 服务关系复杂，运维、测试部署困难

1.1.5 微服务架构

微服务架构模式是从SOA架构模式演变过来， 比SOA架构模式粒度更加精细，让专业的人去做专业的事情（专注），目的是提高效率，每个服务与服务之间互不影响，微服务架构中每个服务独立，互不影响；

微服务的特点：

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

1.2 微服务架构设计原则

微服务是一种架构风格。一个大型的复杂软件应用，由一个或多个微服务组成。系统中的各个微服务可被独立部署，各个微服务之间是松耦合的。每个微服务仅关注于完成一件任务并很好的完成该任务。那么关于微服务的设计原则有哪些呢？

• AKF拆分原则
• 前后端分离原则
• 无状态服务
• RestFul 的通信风格

1.2.1 AKF拆分原则

随着互联网的高速发展，性能越来越成为我们瞩目的焦点，那么如何去提升我们服务器的性能呢？相信最简单和最直接的方法就是：加机器！如果一台不行就两台，两台不行就三台…

如何加机器？加在什么地方最有效？怎样的软件架构加机器才最有效成为我们考虑的重点；

对此，《可扩展的艺术》一书提出了一个更加系统的可扩展模型—— AKF 可扩展立方（Scalability Cube）。这个立方体中沿着三个坐标轴设置分别为：X、Y、Z。

AKF公司的技术专家们从X/Y/Z三个维度来对应用进行扩展。理论上可以将一个单一系统进行无线的延伸扩展；

1.2.1.1 X轴扩展（水平复制）

先自我介绍一下，小编浙江大学毕业，去过华为、字节跳动等大厂，目前阿里P7

深知大多数程序员，想要提升技能，往往是自己摸索成长，但自己不成体系的自学效果低效又漫长，而且极易碰到天花板技术停滞不前！

因此收集整理了一份《2024年最新网络安全全套学习资料》，初衷也很简单，就是希望能够帮助到想自学提升又不知道该从何学起的朋友。

既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，涵盖了95%以上网络安全知识点，真正体系化！

由于文件比较多，这里只是将部分目录截图出来，全套包含大厂面经、学习笔记、源码讲义、实战项目、大纲路线、讲解视频，并且后续会持续更新

需要这份系统化资料的朋友，可以点击这里获取

转存中…(img-1uz7kSOB-1715653542740)]

既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，涵盖了95%以上网络安全知识点，真正体系化！

由于文件比较多，这里只是将部分目录截图出来，全套包含大厂面经、学习笔记、源码讲义、实战项目、大纲路线、讲解视频，并且后续会持续更新

需要这份系统化资料的朋友，可以点击这里获取