微服务之架构演变

随着互联网的发展，网站应用规模不断扩大，网站架构随之不断演变，演变历史大致分为单体应用架构-垂直应用架构-分布式架构-SOA架构-微服务架构-云原生架构

架构演变

单体应用架构

以前网站流量小，只需要一个应用就可以把所有功能部署在一起，比如一个电商系统，包含很多模块，我们部署到一个tomcat里服务器上。

优点：

架构简单，容易开发，部署

缺点：

不易维护、扩展（模块耦合，难以针对某个模块性优化以及水平扩展）
单点容错率低

垂直应用架构

随着访问量增大，单一架构只能依靠增加节点来应对，但是不是多有模块都有较大访问量，所以产生垂直应用架构，把一个应用拆成几个互不相干的应用。

优点

流量分担
解决并发问题
进行优化和水平扩展
提高容错率（一个系统的问题不会影响到其他系统）

缺点：

系统之间相互独立， 无法进行相互调用， 会有重复的开发任务

分布式架构

当垂直应用越来越多，重复的业务代码就会越来越多。这时候，我们就思考可不可以将重复的代码 抽取出来，做成统一的业务层作为独立的服务，然后由前端控制层调用不同的业务层服务呢？

这就产生了新的分布式系统架构。它将把工程拆分成表现层和服务层两个部分，服务层中包含业务 逻辑。表现层只需要处理和页面的交互，业务逻辑都是调用服务层的服务来实现。

优点

抽取公共的功能为服务层，提高代码复用性

缺点

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

SOA架构

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

优点

使用注册中心解决了服务间调用关系的自动调节

缺点

服务间会有依赖关系，一旦某个环节出错会影响较大( 服务雪崩 )
服务关系复杂，运维、测试部署困难

微服务架构

微服务架构在某种程度上是面向服务的架构SOA继续发展的下一步，它更加强调服务的"彻底拆分"。

优点

服务原子化拆分，独立打包、部署和升级，保证每个微服务清晰的任务划分，利于扩展
微服务之间采用Restful等轻量级http协议相互调用

缺点

分布式系统开发的技术成本高（容错、分布式事务等）

云原生架构

云原生架构是为了更好地适应云计算环境而提出的一种软件架构方式。其产生原因包括：

• 弹性和可扩展性需求： 云计算提供了弹性和可扩展性的优势，可以根据负载情况动态调整资源。云原生架构可以更好地利用这些特性，使应用能够快速地响应变化。
• 容器化技术的兴起： 容器化技术如Docker的出现，使得应用能够以一种轻量级、可移植的方式打包和交付。云原生架构将容器作为核心组件，从而使应用更具可移植性和一致性。
• 持续集成/持续交付（CI/CD）： 云原生架构鼓励使用自动化的持续集成和持续交付流程，使得软件交付更加频繁、可靠，从而更好地适应快速变化的市场需求。
• 微服务架构的兴起： 云原生架构通常采用微服务架构，将应用拆分成一组小型、独立部署的服务。这样可以提高开发速度、可维护性和可伸缩性。
• 基础设施即代码（IaC）： 云原生架构鼓励使用基础设施即代码的方法来管理基础设施，使得基础设施的创建、配置和管理变得更加灵活和可重复。

优点：

• 灵活性和可伸缩性： 云原生架构允许应用根据需要自动伸缩，以适应不断变化的负载情况，从而提供更好的用户体验。
• 高可用性： 通过将应用拆分成多个微服务，并在多个地理位置部署，可以实现更高的可用性和容错性。
• 快速交付： 采用云原生架构，应用可以更快地进行持续集成和持续交付，从而更快地交付新功能和修复。
• 资源利用率： 云原生架构可以更好地利用云计算的资源弹性，避免资源浪费。
• 跨平台兼容性： 云原生架构使用容器作为交付机制，可以在不同的云平台和环境中运行，提高了可移植性。

缺点：

• 学习曲线： 云原生架构需要开发团队熟悉新的技术和方法，可能需要一定的学习曲线。
• 复杂性： 拆分成微服务和使用容器等技术增加了系统的复杂性，需要更高的管理和维护成本。
• 安全性： 由于微服务的分布和容器化，可能增加了一些安全风险，需要额外的安全措施。
• 资源消耗： 由于容器化技术本身会带来一定的资源开销，可能需要更多的资源来支持同样的工作负不适用于所有应用： 云原生架构不适用于所有应用，特别是那些对基础架构依赖较大的传统应用。
  总之，云原生架构在适应现代云计算环境和提高开发效率方面具有明显优势，但也需要考虑到其带来的复杂性和管理挑战。是否选择采用云原生架构取决于具体应用场景和团队的技术能力。