互联网架构演变过程

互联网架构经历了几个重要的演变过程，主要包括以下几个阶段：

单一服务器架构：早期的互联网应用通常运行在单一的服务器上，该服务器负责处理所有的请求和数据存储。这种架构简单直接，但容易出现性能瓶颈和单点故障。
客户端/服务器架构：随着互联网应用的增长和复杂性的提高，引入了客户端/服务器架构。应用被拆分为客户端和服务器两部分，客户端负责展示和交互，服务器负责处理业务逻辑和数据存储。这种架构提供了更好的可扩展性和灵活性。
分布式架构：由于互联网应用的规模和需求的增加，分布式架构成为主流。应用被拆分成多个服务或模块，分布在不同的服务器上，并通过网络进行通信和协作。这种架构可以实现横向扩展和高可用性，并提供更好的性能和容错能力。
微服务架构：微服务架构是一种特殊的分布式架构，将应用划分为更小、更独立的服务单元，每个服务单元负责一个特定的业务功能。这些服务可以独立开发、部署和扩展，并通过轻量级的通信机制进行协作。微服务架构提供了更高的可伸缩性、灵活性和快速交付能力。
云原生架构：随着云计算的兴起，云原生架构成为一种新的趋势。云原生架构设计应用程序以最大程度地利用云服务提供商的功能，包括弹性扩展、容器化、自动化管理等。它将应用程序组织为一组松散耦合的微服务，并使用容器编排技术来实现部署和管理。

需要注意的是，以上演变过程并不是线性的，而是相互影响和渗透的。现代互联网应用往往采用多种架构模式的组合，根据具体需求和场景进行选择和调整。

中台战略-共享

中台是指在企业信息化建设中，通过构建一个统一的中间层平台来实现不同业务系统之间的数据共享、功能复用和资源整合。中台的目标是提高企业的信息化效率和灵活性，减少重复建设和维护成本。

中台通常由技术平台、数据平台和应用平台组成。技术平台提供基础设施和共享服务，如计算、存储、网络等；数据平台负责数据集成、存储和管理，以实现数据的流动和共享；应用平台包含各类业务应用，通过接入数据平台和调用共享服务来实现业务功能。

中台的优势包括：

数据共享与一致性：不同业务系统可以通过中台实现数据的共享和一致性，避免数据孤岛问题。
功能复用与快速开发：中台提供了一系列共享的功能和模块，可以被多个业务系统复用，加快系统开发和上线速度。
效率提升与资源优化：通过中台的资源整合和共享，可以提高信息化建设效率，减少资源浪费和重复投入。
变革支撑与创新能力：中台架构可以为企业的业务变革和创新提供支撑，降低系统集成和升级的难度。

中台建设需要企业在组织架构、技术架构和管理模式上进行调整和改革，以实现跨部门、跨系统的数据共享和协同工作。

服务中台化解决问题-数据孤岛

数据孤岛是指在信息化环境中，不同系统、部门或组织之间存在数据隔离和孤立的情况。这种情况下，数据无法共享、交互和利用，导致信息流动受限，效率低下。数据孤岛可能是由于技术标准不统一、数据格式不兼容、安全和隐私等因素造成的。为了解决数据孤岛问题，需要推动数据标准化、建立数据集成和共享机制，并加强数据安全保护和隐私管理。

单体业务模式容易引发以下问题

可扩展性限制：单体应用的架构通常较为简单，很难实现水平扩展和高可用性。当用户量增加或业务需求变化时，扩展和升级整个应用变得困难且昂贵。
部署和发布复杂性：由于整个应用作为一个单元进行部署和发布，任何变更都需要对整个应用进行重新部署，导致耗时和风险增加。
开发效率低下：在单体应用中，不同业务功能紧密耦合，往往需要谨慎修改和测试，开发效率受限。
技术栈限制：单体应用往往有统一的技术栈，限制了使用新技术和工具的灵活性。

中台化的理念和挑战

中台化的理念是将企业的业务进行解构，通过构建一个统一的中间层平台（中台），实现业务系统之间的数据共享、功能复用和资源整合。中台提供标准化的接口、共享的服务和数据，并支持跨部门、跨系统的协同工作。

中台化带来的挑战包括：

组织变革：中台化需要改变企业的组织架构和业务流程，可能面临部门利益的调整和沟通协调的挑战。
技术架构升级：构建中台需要引入新的技术和架构模式，可能需要对现有系统进行改造或替换，对技术团队的能力要求较高。
数据整合和一致性：将不同业务系统的数据整合到中台中，需要解决数据格式、标准和一致性的问题。
安全与隐私：中台涉及多个系统和数据的集成，需要加强数据安全保护和隐私管理，防止数据泄露和滥用。

思考当前业务是否需要构建中台取决于以下因素：

业务规模和复杂度：如果企业业务规模庞大、业务系统繁多且功能重叠，中台可以帮助实现资源整合和效率提升。
跨系统协同需求：如果不同业务系统之间需要进行数据共享、交互和协同工作，中台可以提供统一的接口和平台。
需求变化频繁性：如果业务需求经常变化，需要快速开发和交付新功能，中台的模块化和复用能力可以提供更好的灵活性。
未来扩展性考虑：如果企业未来规划有快速扩展业务或跨行业合作的计划，中台可以为实现这些目标提供支持。

综合考虑以上因素，可以评估当前业务是否适合构建中台，并根据具体情况进行决策。

数据架构

数据架构是指组织和管理数据的结构、组件和流程，以支持企业的数据需求和目标。它包括数据的存储、处理、传输、安全和集成等方面的设计和规划。以下是一些常见的数据架构模式：

集中式数据架构：数据存储和管理集中在一个中心化的系统或数据库中。这种架构简单、易于管理，但可能存在性能瓶颈和单点故障的风险。
分布式数据架构：数据存储和管理分布在多个节点上，通过网络进行通信和协作。分布式架构提供了横向扩展和高可用性，并具有更好的性能和容错能力。
数据仓库架构：数据仓库是一个集成、主题导向的数据存储系统，用于支持决策支持和分析。数据仓库架构包括数据抽取、转换和加载（ETL）过程，以及多维数据模型和报表查询工具。
数据湖架构：数据湖是一个存储结构灵活、大规模的数据存储系统，可以容纳各种类型和格式的原始数据。数据湖架构强调数据的采集和存储，并提供数据探索和分析的能力。
事件驱动架构：事件驱动架构通过捕获和处理事件来实现数据流的管理。它适用于实时数据处理和响应型系统，支持异步、松耦合的组件通信。
服务导向架构（SOA）：SOA架构将业务功能封装为可重用的服务，并通过标准化的接口进行通信。这种架构支持系统集成和数据共享，使得不同应用能够相互协作。
微服务架构：微服务架构将应用程序划分为小而自治的服务单元，每个服务负责一个特定的业务功能。这些服务可以独立开发、部署和扩展，并通过轻量级的通信机制进行协作。

选择适当的数据架构取决于企业的需求、规模和复杂度，以及数据的特点和使用方式。尽管存在多种数据架构模式，实际应用中也常见混合和定制的架构，根据具体情况进行选择和演化。

常见的数据库包括：

关系型数据库（RDBMS）：如MySQL、Oracle、SQL Server、PostgreSQL等，以表格形式存储数据，使用结构化查询语言（SQL）进行数据操作和查询。
非关系型数据库（NoSQL）：如MongoDB、Redis、Cassandra、Elasticsearch等，主要用于处理大规模和非结构化数据，提供更高的可扩展性和灵活性。
图数据库：如Neo4j、Amazon Neptune等，专门用于存储和处理图结构数据，适用于复杂的关系网络分析和图算法应用。
列式数据库：如Apache HBase、Google Bigtable等，数据按列存储，适用于大量读取少量字段的场景，如大数据分析和日志存储。
文档数据库：如MongoDB、Couchbase等，将数据以文档形式存储，适合存储和查询半结构化的文档数据。

持久层框架是用于简化数据库访问和管理的软件框架，常见的有：

Hibernate：Java平台上的ORM（对象关系映射）框架，通过将对象与数据库表之间建立映射关系，实现对象的持久化和数据库操作。
Entity Framework：.NET平台上的ORM框架，提供对象与关系数据库的映射和查询功能，简化数据访问和操作。
MyBatis：Java平台上的持久层框架，通过XML或注解配置数据库与对象之间的映射关系，提供灵活的SQL查询支持。
Django ORM：Python中的ORM框架，为开发者提供了对数据库的高级抽象，简化了数据库操作和查询。

分库和分表是针对大型数据库系统的数据拆分策略：

分库（Sharding）：将一个数据库拆分成多个独立的数据库实例，每个数据库实例存储部分数据。分库可以提高数据处理的并发性和扩展性，减轻单个数据库的负载压力。
分表（Sharding）：将一张表拆分成多个较小的表，每个表存储部分数据。分表可以提高数据读写的并发性和查询性能，减少索引冲突和锁竞争。

分表的常见分法包括：

垂直分表（Vertical Sharding）：按照业务功能或数据类型将表的列分割到不同的表中，使得每个表只包含相关的数据字段。
水平分表（Horizontal Sharding）：按照某个条件（如范围、哈希值等）将数据行分散到不同的表中，使得每个表只包含部分数据。

缓存在应用程序中用于暂时存储和快速访问数据，常见的问题包括：

数据一致性：缓存中的数据可能与后端数据库不一致，需要考虑缓存更新策略，保持数据的一致性。
缓存过期和淘汰：缓存中的数据可能过期或被淘汰，需要合理设置缓存过期时间和采用适当的淘汰算法（如LRU、LFU等）。
写入并发冲突：多个并发写操作可能导致缓存数据的不一致性或竞争条件，需要使用锁或乐观并发控制来处理并发写入。
内存限制和性能折衷：缓存的大小受限于可用内存，需要权衡的大小和性能。如果缓存过小，可能无法覆盖频繁访问的数据，导致缓存命中率下降；而过大的缓存则会占用过多内存资源。

缓存雪崩：当缓存中大量数据同时失效或被淘汰时，可能导致后端数据库压力剧增，引发性能问题甚至系统宕机。为了应对缓存雪崩，可以采用缓存的失效时间错开、增加缓存层级、设置容错机制等策略。
热点数据访问：某些数据可能会被频繁访问，导致缓存故障，并产生大量请求集中到少数节点的情况。这时可以使用分布式缓存或数据预热等方法来缓解热点数据的访问压力。

不同的缓存问题适用于不同的场景：

高并发读取场景：在请求读取操作频繁且数据更新较少的情况下，缓存可以显著提高读取性能和响应速度。
数据一致性要求高的场景：对于需要保持严格一致性的数据，如金融交易和订单处理等，需要谨慎处理缓存与数据库之间的数据同步和更新，以确保数据的准确性与一致性。
大规模数据处理场景：在大数据分析、机器学习等需要快速访问和处理海量数据的场景中，缓存可以提供快速的数据访问和计算结果缓存，加快处理速度。
低延迟要求的实时应用场景：对于实时通信、游戏互动等需要快速响应的应用，使用缓存可以减少后端数据库查询压力，降低响应延迟。

综合考虑业务需求、数据特性和系统性能要求，可以选择适当的缓存策略和技术，以优化系统性能并解决相应的问题。

应⽤架构

如何理解微服务与SOA，分布式的关系？

微服务（Microservices）和SOA（Service-Oriented Architecture）是两种不同的架构风格，但它们在某些方面存在联系和相似之处。

微服务与SOA：微服务和SOA都强调将应用程序划分为独立、可重用的服务单元，并通过标准化接口进行通信。然而，微服务更加注重服务的自治性和独立性，每个微服务通常较小且专注于特定的业务功能。SOA则更加强调企业级集成和跨组织协作，服务规模较大且可能包含多个业务功能。
分布式与微服务/ SOA：微服务和SOA都属于分布式系统范畴，因为它们将应用程序的不同部分分布到多个节点或服务器上。分布式系统可以通过网络进行通信和协作，以实现高可用性、可伸缩性和容错性。

常⽤的分布式服务框架有哪些？

常用的分布式服务框架有以下几种：

Spring Cloud：基于Spring框架的一套开源工具集，提供了许多用于构建分布式系统的解决方案，如服务注册与发现、负载均衡、容错机制等。
gRPC：由Google开源的高性能RPC框架，支持多种编程语言，使用基于Protocol Buffers的IDL（接口定义语言）进行服务定义和通信。
Apache Dubbo：阿里巴巴开源的高性能、轻量级的RPC框架，提供了完善的微服务治理解决方案，包括服务注册与发现、负载均衡、容错机制等。
Netflix OSS：Netflix开源的一套分布式服务组件集合，包括Eureka（服务注册与发现）、Ribbon（负载均衡）、Hystrix（容错机制）等，用于构建弹性、可靠的分布式系统。
Apache Kafka：分布式流平台，用于高吞吐量、低延迟的消息发布和订阅，支持分布式流处理和事件驱动架构。

除以上框架外，还有其他分布式服务框架和中间件，如Service Mesh（Istio、Linkerd）、Apache Thrift、Axon Framework等，根据具体需求和技术栈选择适合的框架可以帮助构建稳定、可扩展的分布式系统。

部署架构是指将应用程序或系统的组件和资源配置在不同的环境中以实现功能的交付和运行。以下是一些常见的部署架构：

单体部署（Monolithic Deployment）：将整个应用程序作为一个单一的部署单元，在同一个服务器或容器中进行部署。所有的组件共享相同的资源，如数据库连接和文件系统。这种架构简单且易于管理，适用于小型应用。
分层部署（Layered Deployment）：将应用程序划分为多个逻辑层，并将每个层部署在独立的服务器或容器中。例如，可以将表示层、业务逻辑层和数据访问层分别部署在不同的服务器上。这种架构使得每个层可以独立扩展和升级，增加了灵活性和可维护性。
客户端-服务器部署（Client-Server Deployment）：将应用程序分为客户端和服务器两个部分，并在不同的机器或虚拟环境中进行部署。客户端负责用户界面和交互，而服务器处理业务逻辑和数据存储。这种架构适用于需要大量客户端访问的应用程序。
三层架构（Three-Tier Architecture）：将应用程序划分为表示层、业务逻辑层和数据访问层三个部分，并将它们分别部署在不同的服务器或容器中。表示层处理用户界面和交互，业务逻辑层负责处理业务规则，数据访问层负责与数据库或其他数据源交互。这种架构有助于实现模块化和可扩展的系统。
容器化部署（Containerized Deployment）：使用容器技术（如Docker）将应用程序及其依赖项打包为独立的容器镜像，并在容器编排平台（如Kubernetes）上进行部署。容器化部署提供了资源隔离、易于扩展和部署一致性等优势。
无服务器部署（Serverless Deployment）：将应用程序的业务逻辑部署到无服务器计算平台（如AWS Lambda、Azure Functions等），无需关心底层的服务器和基础设施。开发人员只需关注代码的编写和函数的配置。

根据应用程序的规模、复杂性和需求，可以选择适合的部署架构。在实践中，也可以采用混合的部署方式，结合多种架构来满足不同的需求。

部署架构

部署架构是指将应用程序或系统的组件和资源配置在不同的环境中以实现功能的交付和运行。以下是一些常见的部署架构：

单体部署（Monolithic Deployment）：将整个应用程序作为一个单一的部署单元，在同一个服务器或容器中进行部署。所有的组件共享相同的资源，如数据库连接和文件系统。这种架构简单且易于管理，适用于小型应用。
分层部署（Layered Deployment）：将应用程序划分为多个逻辑层，并将每个层部署在独立的服务器或容器中。例如，可以将表示层、业务逻辑层和数据访问层分别部署在不同的服务器上。这种架构使得每个层可以独立扩展和升级，增加了灵活性和可维护性。
客户端-服务器部署（Client-Server Deployment）：将应用程序分为客户端和服务器两个部分，并在不同的机器或虚拟环境中进行部署。客户端负责用户界面和交互，而服务器处理业务逻辑和数据存储。这种架构适用于需要大量客户端访问的应用程序。
三层架构（Three-Tier Architecture）：将应用程序划分为表示层、业务逻辑层和数据访问层三个部分，并将它们分别部署在不同的服务器或容器中。表示层处理用户界面和交互，业务逻辑层负责处理业务规则，数据访问层负责与数据库或其他数据源交互。这种架构有助于实现模块化和可扩展的系统。
容器化部署（Containerized Deployment）：使用容器技术（如Docker）将应用程序及其依赖项打包为独立的容器镜像，并在容器编排平台（如Kubernetes）上进行部署。容器化部署提供了资源隔离、易于扩展和部署一致性等优势。
无服务器部署（Serverless Deployment）：将应用程序的业务逻辑部署到无服务器计算平台（如AWS Lambda、Azure Functions等），无需关心底层的服务器和基础设施。开发人员只需关注代码的编写和函数的配置。

根据应用程序的规模、复杂性和需求，可以选择适合的部署架构。在实践中，也可以采用混合的部署方式，结合多种架构来满足不同的需求。

常见的代理服务器有以下几种：

HTTP代理服务器：作为HTTP请求的中转站点，用于转发和缓存HTTP请求。常见的HTTP代理服务器有Nginx、Apache HTTP Server等。它们属于应用层（第七层）代理。
反向代理服务器：接收来自客户端的请求，并将其转发给后端服务器进行处理，然后将响应返回给客户端。反向代理服务器可以实现负载均衡、SSL终止、缓存等功能。常见的反向代理服务器有Nginx、HAProxy等。它们通常位于应用层（第七层）。
TCP/UDP代理服务器：用于转发TCP或UDP数据流量，通常用于代理网络连接而不仅限于HTTP请求。常见的TCP/UDP代理服务器有Squid、HAProxy等。它们通常位于传输层（第四层）或网络层（第三层）。
SOCKS代理服务器：SOCKS是一种网络协议，用于通过防火墙和NAT网关进行安全的TCP和UDP通信。SOCKS代理服务器可将客户端的请求转发到目标服务器。常见的SOCKS代理服务器有Shadowsocks、Dante等。它们通常位于传输层（第四层）或应用层（第七层）。

Docker的编排工具有以下几种：

Docker Compose：用于定义和管理多个Docker容器的编排工具。通过一个YAML文件来定义服务、网络和卷，并可以使用单个命令启动、停止和管理整个应用程序的容器。
Kubernetes（K8s）：是一个开源容器编排平台，用于自动部署、扩展和管理容器化应用程序。Kubernetes提供了强大的功能和资源管理机制，包括自动伸缩、服务发现、负载均衡等。
Docker Swarm：是Docker原生的集群和编排解决方案，用于在多个主机上运行和管理Docker容器。Docker Swarm提供了一组命令和API，用于创建和管理容器集群。

这些编排工具都可以帮助简化容器化应用程序的部署和管理，提高可靠性和可伸缩性。选择合适的编排工具取决于需求和技术栈。

架构思想

任何体系的成型不是⼀蹴⽽就，随着访问量，数据量的增⻓，业务需求在推动技术架构的发展变⾰。

知⾏合⼀，做之前，先考虑意义
原⽣优于定制，约定⼤于配置
什么都是，最后会沦落到什么都不是
控制技术欲，不要瞎折腾
留下扩展，但不要想到 100 年后
没有最好的，只有最合适的
够⽤就好，玩的越花，⻛险越⼤
简约最美