【架构】系统架构分类
架构分类
软件开发的常常提到的架构的概念:
比如说单体架构、垂直应用架构、分布式架构、SOA架构、微服务架构
单体架构
单体应用架构（Monolithic Architecture）是一种传统的应用架构模式，将应用程序作为一个整体部署和运行在单一的软件实体中。在单体应用架构中，应用的各个功能模块紧密地耦合在一起，共享相同的运行环境和数据库。
应用场景
单体应用架构适用于一些简单和小规模的应用场景，如内部管理系统、小型电子商务网站等。这种架构模式通常适用于初创企业或小型业务，因为它具有快速开发、部署和维护的优势。
优点
1）简单易用
单体应用架构通常比较简单直观，易于开发、测试和维护。开发人员可以更容易理解整个代码库，降低开发复杂性。
2） 性能较好
由于应用程序的各个模块都在同一进程中运行，它们可以共享内存和资源，减少了通信开销，因此在某些情况下可以提供较好的性能。
缺点
1）可扩展性有限
单体应用架构通常较难进行水平扩展，无法根据需求和负载增长进行动态扩展。当用户流量和数据量增长时，会面临性能瓶颈。
2） 耦合性高
在单体应用架构中，各个模块之间紧密耦合，一旦其中一个模块出现问题，可能会影响整个应用的稳定性和可用性。
2） 难以更新和部署
由于整个应用作为一个整体进行部署和更新，当需要更新其中的一个功能或组件时，需要重新部署整个应用，导致停机时间较长。
综上所述，单体应用架构适用于一些简单和小规模的应用场景，但在大型和复杂应用的场景下，会面临一些挑战，因此需要考虑其他的应用架构模式，如微服务架构。正是由于单体应用架构存在着诸多的缺点，才逐渐演变为垂直应用架构。接下来，我们就来看看垂直应用架构。
垂直应用架构
随着企业业务的不断发展，发现单节点的单体应用不足以支撑业务的发展，于是企业会将单体应用部署多份，分别放在不同的服务器上。但是，此时会发现不是所有的模块都会有比较大的访问量。如果想针对项目中的某些模块进行优化和性能提升，此时对于单体应用来说，是做不到的。于是乎，垂直应用架构诞生了。
垂直应用架构是一种将一个应用程序按照功能或业务垂直划分的架构模式。在垂直应用架构中，每个功能模块或业务模块由一个独立的组件或服务来处理，它们之间通常通过接口进行通信。
我们将单体应用架构拆分为垂直应用架构之后，一旦访问量变大，我们只需要针对访问量大的业务增加服务器节点即可，无需针对整个项目增加服务器节点了。这种架构的特点是对不同的应用模块单独部署。或者对同一个应用模块部署在不同的机器上。
这里，我们同样以电商系统为例，在垂直应用架构下，我们可以将整个电商项目拆分为：电商交易系统、后台管理系统、CMS管理系统等。
应用场景
垂直应用架构适用于一些复杂的应用场景，特别是需要特定功能集成或者需要处理大量业务逻辑的场景。每个业务模块独立运行，可以独立扩展和部署，这使得团队可以更容易地并行开发和维护各个模块。此外，垂直应用架构也可以提供更好的系统可用性和可靠性，因为一个模块的故障不会影响整个系统的运行。
优点
系统进行了拆分，
可根据不同系统的访问情况，有针对性的进行优化。能够实现应用的
水平扩展。各系统能够
分担整体访问的流量，解决了并发问题。一个系统发生了故障，不应用其他系统的运行情况，提高了整体的容错率。
缺点
不同的业务模块可能需要
重复的功能，这可能导致代码冗余和资源浪费。模块化的架构可能导致
模块之间的依赖关系复杂化，增加了系统的复杂性和耦合度。在垂直应用架构中，
跨模块的通信可能会带来延迟和性能问题。拆分后的
各系统之间相对比较独立，无法进行互相调用。各系统难免存在重叠的业务，会存在重复开发的业务，
后期维护比较困难。
分布式架构
我们将系统演变为垂直应用架构之后，当垂直应用越来越多，重复编写的业务代码就会越来越多。此时，我们需要将重复的代码抽象出来，形成统一的服务供其他系统或者业务模块来进行调用。此时，系统就会演变为分布式架构。
分布式架构是一种将一个应用程序的不同功能模块或服务分布在多台独立的计算机或服务器上的架构模式。在分布式架构中，这些功能模块通过网络进行通信和协作，共同完成应用程序的业务逻辑。
在分布式架构中，我们会将系统整体拆分为服务层和表现层。服务层封装了具体的业务逻辑供表现层调用，表现层则负责处理与页面的交互操作。
应用场景
分布式架构适用于需要处理高并发、大规模数据处理和需要高可用性的应用场景。例如，电子商务平台、社交媒体平台、大数据处理系统等都是典型的分布式应用场景。通过将不同的功能模块分散在不同的服务器上，分布式架构可以实现高度的水平扩展，并且可以更好地应对大量请求和数据处理。
优点
- 将重复的业务代码抽象出来，形成
公共的访问服务，提高了代码的复用性。 - 高性能：分布式架构可以通过水平扩展来处理
高并发的请求，实现负载均衡，提高系统的吞吐量和响应速度。 - 可靠性和可用性：由于应用程序的功能模块分布在多台服务器上，
当其中某一台服务器发生故障时，其他服务器仍然可以继续提供服务，提高了系统的可靠性和可用性。 - 扩展性：
分布式架构可以根据需求动态扩展服务器数量，以适应业务的发展，从而提高了系统的扩展性。
缺点
复杂性：分布式系统的设计、开发和维护相对
复杂，需要考虑到网络通信、数据同步、一致性等问题。一致性和可靠性：由于网络通信的不确定性，分布式系统可能
面临数据一致性和可靠性的问题，需要额外的机制来保证数据的一致性和可靠性。调试和定位问题：当分布式系统出现故障或性能问题时，
调试和定位问题可能会更加困难，需要更复杂的工具和技术。
微服务架构
微服务架构是一种将应用程序划分为一组小型、独立、可独立部署的服务的架构模式。在微服务架构中，每个服务都专注于完成一个特定的业务功能，并通过轻量级的通信机制（通常是通过HTTP或消息队列）相互协作。
微服务架构是从SOA架构演变而来的，主要区别在于规模和粒度。微服务将SOA中的服务进一步细分，将每个服务划分为更小、更独立的服务单元，强调服务的自治性和可独立部署性。同时，微服务架构采用轻量级的通信机制，如HTTP和消息队列，与SOA中的重型中间件相比，减少了开销和复杂性。
将多个应用架构分层展示，分成代理层、网关层、服务中心层，中间件层，中间件层负责权限认证，分库分表（多租户功能），服务的流量控制功能，卒后到存储层，存储层兼容不同的数据库类型。
对于服务中心的服务层，也是可以具体分为业务服务模块的服务池以及基础服务层，基础服务层可以包含不同的数据库访问等基础服务、任务调度，数据处理服务等，在扩充数据库个数，以及数据库类型时不影响业务服务。
场景
1、大规模复杂应用：微服务可以将复杂应用程序划分为若干个小型服务，从而提供更好的可维护性和可扩展性。
2、高并发应用：由于微服务是独立部署的，可以根据需要进行水平扩展，可以更好地应对高并发的请求。
3、跨团队开发：每个微服务都可以由一个小团队负责开发和维护，提供更高的并行开发和自治性。
优点
1、独立部署：每个微服务都可以独立部署，不会影响其他服务，提高了部署的灵活性和可靠性。服务彻底拆分，各服务独立打包、独立部署和独立升级。不存在重复部署服务的问题，部署容量小。
2、独立可扩展：由于每个微服务都是独立的，可以根据需要进行单独的扩展，提高了系统的可扩展性和弹性。每个微服务负责的业务比较清晰，利于后期扩展和维护。
3、技术异构性：不同的微服务可以使用不同的技术栈和编程语言实现，根据业务需求选择最适合的技术，提高了技术的灵活性。
4、可以支持小批量的快速迭代敏捷开发。
缺点
1、分布式系统的复杂性：微服务架构引入了分布式系统的复杂性，包括服务之间的通信和协调、数据一致性等问题，需要仔细考虑和解决。
2、需要比较高的架构能力开发的成本比较高。
总的来说，微服务架构适用于大规模复杂应用和高并发场景，具有独立部署和独立可扩展等优点，但也引入了分布式系统的复杂性和运维成本的增加，目前由于引入了运维自动化流程例如devops或者dataops，降低了微服务运维的难度，也使得微服务架构普遍应用。