https://developer.aliyun.com/article/1491356
数据库系统架构风格
https://cuiyonghua.blog.csdn.net/article/details/139441129
核心总结索引
https://blog.csdn.net/qq78442761/article/details/86710096
https://blog.csdn.net/g984160547/category_12701163.html
https://blog.csdn.net/u010095372/category_12522365.html?spm=1001.2014.3001.5482
https://blog.csdn.net/u010986241?type=blog
https://www.cnblogs.com/zhulimin/p/12643209.html
数据仓库 阿里五层模型架构
https://blog.csdn.net/qusikao/article/details/142741634
1.论企业应用系统的数据持久层架构设计
数据持久层（Data Presistence Layer）通常位于企业应用系统的业务逻辑层和数据源层之间，为整个项目提供一个高层、统一、安全、并发的数据持久机制，完成对各种数据进行持久化的编程工作，并为系统业务逻辑层提供服务。它能够使程序员避免手工编写访问数据源的方法，使其专注于业务逻辑的开发，并且能够在不同项目中重用本框架，这大大简化了数据的增加、删除、修改、查询功能的开发过程，同时又不丧失多层结构的天然优势，集成延续应用系统架构的可伸缩性和可扩展性。当运用关系型数据作为数据存储机制时，在业务层与数据源之间加入数据持久层，能够解决对象与关系的“阻抗不匹配”问题，将对象的状态持久化存储到关系型数据库中。
https://blog.csdn.net/weixin_41631494/article/details/140119301
2.论分布式设计与实现
分布式是指将一个系统或任务分解成多个子部分，并在多个计算机或服务器之间进行协同工作的方式。每个子部分都可以在不同的计算机节点上运行，彼此之间通过网络进行通信和协调。分布式技术在当今互联网应用中起着重要作用，例如大规模搜索引擎、社交网络和电子商务平台等。常见的分布式系统包括分布式数据库、分布式存储系统、分布式计算系统等。这些系统通过将数据、计算和功能分散到多个节点上，可以提供更高的性能、可伸缩性和容错性。分布式系统的设计和实现需要解决一系列挑战，例如节点之间的通信和同步、数据一致性的维护、负载均衡、故障恢复等。为了解决这些挑战，通常会使用一些分布式算法和协议，如一致性哈希、PaxOS、Raft等。
https://blog.csdn.net/weixin_41631494/article/details/140119044
3.信息系统安全体系设计
https://blog.csdn.net/weixin_41631494/article/details/140117561
4.论基于架构的软件设计方法及应用
论湖仓一体架构及其应用
湖仓一体是一种新型的开放式架构，打通了数据仓库和数据湖，将数据仓库的高性能及管理能力与数据湖的灵活性融合起来，底层支持多种数据类型并存，能实现数据间的相互共享，上层可以通过统一封装的接口进行访问，可同时支持实时查询和分析，为企业进行数据治理带来了更多的便利性。湖仓一体可在数据入湖后原地进行数据处理与分析，能有效避免数据冗余及流动导致的算力、网络及成本开销，可作为超大型ODS（Operational Data Store）存储贴源数据（贴源数据指经过ETL过程后的数据），实现全量数据的实时处理。
湖仓一体架构在数据管理中主要有以下几大关键特征。
（1）支持分析多种类型数据。湖仓一体架构可为多应用程序提供数据的入库、转换、分析和访问，支持的数据类型包括结构化和非结构化类型，如文本、图像、视频、音频等，还支持半结构化数据，如JSON等。
（2）数据可治理，避免产生数据沼泽。湖仓一体架构具有健全的治理和审计机制，能够避免数据沼泽现象的出现。
（3）事务支持。在企业中，数据库往往要为业务系统提供并发的数据读取和写入。湖仓一体架构支持事务的ACID特性（即原子性、一致性、 隔离性、 持久性），可确保并发访问，尤其是可确保在SQL访问模式下的数据一致性、正确性。
（4）BI支持。湖仓一体支持直接在源数据上使用BI工具，这样可以提高分析效率，降低数据延时。另外，相比于在数据湖和数据仓库中分别操作两个副本的方式，湖仓一体更具成本优势。
（5）存算分离。湖仓一体采用存算分离架构，可使系统能够扩展到更大规模的并发能力和数据容量，能满足新时代对于分布式数据架构的要求。
（6）开放性。湖仓一体采用开放、标准化的存储格式（例如行存、列存、块存），能提供丰富的API支持。因此，各种工具和引擎（包括机器学习/python/R库）可以高效地对数据进行直接访问。
从落地性来看，湖仓一体技术架构落地目前主要有以下三种方式。
（1）基于hadoop体系的数据湖向数据仓库能力扩展，湖中建仓，从数据湖进化到湖仓一体。湖仓一体结合了数据湖和数据仓库特点，直接在用于数据湖的低成本存储上实现与数据仓库中类似的数据结构和数据管理功能。目前，主要有Netflix等开源企业在探索此技术路线。
（2）基于自身云平台或第三方对象存储（如OSS、S3、Ceph等），基于hadoop或自研技术进行湖仓一体能力的搭建。目前，在探索此技术路线的通常是各大云厂商，如AWS、阿里云、华为云等。
（3）以数据库为基础，自研分布式平台，从调度、计算到存储不依赖第三方平台，形成可以灵活地在公有云、私有云、裸金属等场景独立部署使用的能力。技术方向上更注重于实时高并发场景及非结构化数据治理，并逐步向更广泛的数据分析场景发展。目前，主要厂商以Snowflakes、Databricks、巨杉数据库等为代表。
https://developer.aliyun.com/article/785376
云原生架构的七个原则。
论云原生架构及其应用
云原生架构设计原则有七条。
1.服务化原则
通过服务化架构拆分不同生命周期的业务单元，实现业务单元的独立迭代，从而加快整体迭代速度，保证迭代的稳定性。同时，服务化架构采用的是面向接口编程方式，增加了软件的复用程度，增强了水平扩展的能力。服务化设计原则还强调在架构层面抽象化业务模块之间的关系，从而帮助业务模块实现基于服务流量（而非网络流量）的策略控制和治理，而无须关注这些服务是基于何种编程语言开发的。通过微服务，需要将单体应用进一步拆分，按业务边界重新划分成分布式应用，使应用与应用之间不再直接共享数据，而是通过约定好的契约进行通信，以提高扩展性，业务化垂直扩展（Scale up），并将微服务数据水平扩展(Scale Out)。
2.弹性原则
系统部署规模可以随着业务量的变化自动调整大小，而无须根据事先的容量规划准备固定的硬件和软件资源。优秀的弹性能力不仅能够改变企业的IT成本模式，使得企业不用再考虑额外的软、硬件资源成本支出（闲置成本），也能更好地支持业务规模的爆发式扩张，不再因为软、硬件资源储备不足而留下遗憾。简言之，弹性原则是指系统部署规模可以随着业务量变化自动调整大小，而无须根据事先的容量规划准备固定的硬件和软件资源。
3.可观测性原则
强调主动性，在云计算这样的分布式系统中，主动通过日志、链路跟踪和度量等手段，让一次App点击所产生的多次服务调用耗时、返回值和参数都清晰可见，甚至可以下钻到每次第三方调用、SQL请求、节点拓扑、网络响应等信息中。运维、开发和业务人员通过这样的观测能力可以实时掌握软件的运行情况，并获得前所未有的关联分析能力，以便不断优化业务的健康度和用户体验。简言之，可观测性更强主动性，在云计算这样的分布式系统中，主动通过日志、链路跟踪和度量等手段，让一次App点击产生的多次服务调用耗时、返回值、参数都可见。
4.韧性原则
韧性是指当软件所依赖的软、硬件组件出现异常时，软件所表现出来的抵御能力。这些异常通常包括硬件故障、硬件资源瓶颈（如CPU或网卡带宽耗尽）、业务流量超出软件设计承受能力、影响机房正常工作的故障或灾难、所依赖软件发生故障等可能造成业务不可用的潜在影响因素。业务上线之后，在运行期的大部分时间里，可能还会遇到各种不确定性输入和不稳定依赖的情况。当这些非正常场景出现时，业务需要尽可能地保证服务质量，满足当前以联网服务为代表的“永远在线”的要求。因此，韧性能力的核心设计理念是面向失败设计，即考虑如何在各种依赖不正常的情况下，减小异常对系统及服务质量的影响并尽快恢复正常。简言之，韧性是指当软件所依赖的软、硬件组件出现异常时，软件所表现出来的抵御能力。韧性原则的实践与常见架构主要包括：服务异步化能力、服务质量能力（重试/限流/降级/熔断/反压）、主从模式、集群模式、多可用区（AZ）的高可用、单元化、跨区域（Region）容灾、异地多活容灾等。
5.自动化原则
通过IaC、GitOps、OAM、Operator和大量自动化交付工具在CI/CD（持续集成/持续交付）流水线中的实践，企业可以标准化企业内部的软件交付过程，也可以在标准化的基础上实现自动化，即通过配置数据自描述和面向终态的交付过程，实现整个软件交付和运维的自动。
6.零信任原则
传统安全架构认为防火墙内的一切都是安全的，而零信任模型假设防火墙边界已经被攻破，且每个请求都来自于不可信网络，因此每个请求都需要经过验证。第一，不能基于IP配置安全策略；第二，身份应该成为基础设施；第三，假设物理边界被攻破，需要严格控制安全半径。
7.架构持续演进原则
云原生架构本身也应该且具备持续演进的能力，而不是一个封闭式的，被设计后一成不变的架构。特别是在业务高速迭代时，更应该考虑如何保证架构演进与业务发展之间的平衡。演进式架构是指软件开发的初始阶段，就可以通过可拓展和松耦合设计，让后续可能发生的变更更加容易，升级性重构的成本更低，并且能够发生在开发实践、发布实践和整体敏捷度等软件生命周期中的任何阶段。
论NoSQL数据库技术及其应用
目前常见的NoSQL数据库主要分为四类：
（1）键值（Key-value）存储数据库
该数据库主要会使用到一个哈希表，这个表中有一个特定的键和一个指针指向特定的数据。Key-Value模型对于IT系统来说的优势在于简单、易部署。但是如果DBA只对部分值进行查询或更新Key-Value就显得效率低下了。
常见的键值存储数据库有：Tokyo Cabinet/Tyrant、Redis、Voldemort、Oracle BDB。
（2）列存储数据库
该数据库通常是用来应对分布式存储的海量数据。键仍然存在，但是它们的特点是指向了多个列，这些列是由列家族来安排的。
常见的列存储数据库有：Cassandra、Hbase、Riak。
（3）文档型数据库
该数据模型是版本化的文档，半结构化的文档以特定的格式存储，例如JSON。文档型数据库可以看作键值数据库的升级版，允许之间嵌套键值。而且文档型数据库比键值数据库的查询效率更高。
常见的文档型数据库有：CouchDB、MongoDB、SequoiaDB。
（4）图（Graph）数据库
该数据库使用图模型，并且能够扩展到多个服务器上。NoSQL数据库没有标准的查询语句（SQL），因此进行数据库查询需要指定数据模型。许多NoSQL数据库都有REST式的数据接口或者查询API。
常见的图数据库有：Neo4J、InfoGrid、Infinite Graph。
NoSQL数据库在以下几种情况下比较适用：
①数据模型比较简单；
②需要灵活性更强的IT系统；
③对数据库性能要求较高；
④不需要高度的数据一致性；
⑤对于给定key，比较容易映射复杂值的环境。
论企业集成架构设计及其应用
企业集成架构有三类，分别是数据集成、应用集成、企业集成。
（1）数据集成，是为了解决不同应用和系统间的数据共享和交换需求，具体包括共享信息管理、共享模型管理和数据操作管理三个部分。
共享信息管理通过定义统一的集成服务模型和共享信息访问机制，完成对集成平台运行过程中产生数据信息的共享、分发和存储管理；
共享模型管理则是提供数据资源配置管理、集成资源关系管理、资源运行生命周期管理及相应的业务数据协同监控管理等功能；
数据操作管理则为集成平台用户提供数据操作服务，包括多通道的异构模型之间的数据转换、数据映射、数据传递和数据操作等功能服务。
数据集成的模式包括：数据联邦、数据复制模式、基于结构的数据集成模式。
（2）应用集成，是指两个或多个应用系统根据业务逻辑的需要而进行的功能之间的互相调用和互操作。
应用集成需要在数据集成的基础上完成。
应用集成在底层的网络集成和数据集成的基础上实现异构应用系统之间应用层次上的互操作。
它们共同构成了实现企业集成化运行最顶层集成所需要的技术层次上的支持。
应用集成的模式包括：集成适配器模式、集成信使模式、集成面板模式和集成代理模式。
（3）企业集成，应用软件从功能逻辑上可以分为表示、业务逻辑和数据三个层次。
表示层负责完成系统与用户交互的接口定义；
业务逻辑层主要根据具体业务规则完成相应业务数据的处理；
数据层负责存储由业务逻辑层处理所产生的业务数据，它是系统中相对稳定的部分。
支持企业间应用集成和交互的集成平台通常采用多层结构，其目的是在最大程度上提高系统的柔性。在集成平台的具体设计开发中，还需要按照功能的通用程度对系统实现模块进行分层。
企业集成的模式包括：前段集成模式、后端集成模式和混合集成模式。