1. 数据仓库架构风格的优缺点：
优点：
1）数据统一保存在中央数据仓库，数据处理流程相对独立，支持交互式处理。
缺点：
1）仓库风格不支持并行，效率低。
2）仓库风格容错性和健壮性好。
2.仓库风格相关概念：仓库风格是一种数据共享风格，主要有两大类：
传统数据库：传统数据库是由输入流中的事件来驱动信息处理，把执行结构存储到中央数据单元。
黑板：由中央数据单元的当前状态来驱动系统运行，用来解决状态冲突并处理可能存在的不确定性知识源。黑板常用信号处理，如语音识别、模式识别、机器翻译、句法分析等。
优点：
1）便于多客户共享大量数据，不必关心数据的产生、由谁提供、如何提供等；
2）便于将构件作为知识源添加到系统中来；
3）解决问题的多方法性；
4）具有可修改性和可维护性；
5）有可重用的知识源
6）支持容错性和健壮性
缺点：
1）对共享数据结构，不同知识源要达成一致
2）需要同步机制、加锁机制来保障数据的完整性和健壮性，增加了系统设计的复杂度
3）测试困难
4）缺少对并行机的支持，效率低
5）开发成本高
3.管道过滤器架构的概念：管道过滤器架构风格是由一系列处理单元（过滤器）组成，每个单元的输出是下一个单元的输入。过滤器负责处理数据，管道负责数据传输，如Linux/Unix中的shell，传统的编译器就是管道过滤器风格；
优点：
1）高内聚，过滤器是执行特定功能的处理服务，具有较强的内聚性
2）低耦合，过滤器之间仅通过管道进行通信
3）可重用，支持过滤器的重用
4）能简单地实现并发或者顺序系统
5）可扩展性，容易增加新的过滤器
6）灵活性，过滤器功能可重新定义，管道路线可改变
缺点：
1）管道中数据传输需要通用标准
2）难以支持基于事件的交互
5.企业集成的概念：
1）数据集成：是为了解决不同应用和系统之间的数据共享和交换需求，具体包括共享信息管理、共享模型管理和数据操作管理三个部分。共享信息管理通过定义统一的集成服务模型和共享信息访问机制，完成对集成平台运行过程中产生数据信息的共享、分发和存储管理；共享模型管理则提供数据资源配置管理、基础资源关系管理，资源运行生命周期管理及相应的业务数据协同监控管理等功能；数据操作管理则为集成平台用户提供数据操作服务，包括多通道的异构模型之间的数据转换、数据映射、数据传递和数据操作等功能服务。数据集成的模式包括：数据联邦、数据复制模式、基于结构的数据集成模式；
2）应用集成：是指两个或者多个应用系统根据业务逻辑的需要而进行的功能之间的相互调用和互操作。应用集成需要在数据集成的基础上完成。应用集成在底层的网络集成和数据集成的基础上实现异构应用系统之间应用层次上的互操作。它们共同构成了实现企业集成化运行最顶层集成所需要的技术层次上的支持。应用集成的模式包括：集成适配器模式、集成信使模式、集成面板模式和集成代理模式。
3）企业集成：应用软件系统从功能逻辑上可以分为表示、业务逻辑和数据三个层次。其中表示层负责完成系统与用户交互的接口定义；业务逻辑层主要根据具体业务规则完成相应业务数据的处理；数据层负责存储由业务逻辑层处理所产生的业务数据，它是系统中相对稳定的部分。支持企业之间应用集成和交互的集成平台通常采用多层结构，其目的是在最大程度上提高系统的柔性。在集成平台的具体设计开发中，还需要按照功能的通用程度对系统实现模块进行分层。企业集成的模式包括：前端集成模式、后端集成模式和混合集成模式。
6.软件缺陷相关的定义：软件缺陷（Defect）又称为bug，所谓的软件缺陷，即为计算机软件或者程序中存在的某种破坏正常运行能力的问题、错误、或者隐藏的功能缺陷。缺陷的存在会导致软件产品在某种程度上不能满足用户的需要。IEEE729-1983对缺陷有一个标准的定义：从产品内部看，缺陷是软件产品开发或者维护过程中存在的错误，毛病等各种问题：从产品外部看，缺陷是系统所需要实现的某种功能的失效或违背。
产生的原因：在软件开发的过程中，软件缺陷的产生是不可避免的。那么造成软件缺陷的主要原因有哪些？从软件本身、团队和技术团队等角度分析，就可以了解造成软件缺陷的主要因素。软件缺陷的产生主要是由软件产品的特点和开发过程决定的。
软件本身：
1）需求不清晰，导致设计目标偏离客户的需求，从而引起功能或产品特征上的缺陷。
2）系统结构非常复杂，而又无法设计成一个很好的层次结构或组件结构，结果导致意想不到的问题或系统维护、扩充上的困难；即使设计成良好的面向对象的系统，由于对象、类太多，很难完成对各种对象、类相互作用的组合测试，而隐藏着一些参数传递，方法调用、对象状态变化等方面问题。
3）对程序逻辑路径或数据范围的边界考虑不够周全，漏掉某些边界条件，造成容量或边界错误。
4）对一些实时应用，要进行精心设计和技术处理，保证精确的时间同步，否则容易引起时间上不协调，不一致带来的问题。
5）没有考虑系统崩溃后的自我恢复或数据的异地备份、灾难性恢复等问题，从而存在系统安全性、可靠性的隐患。
6）系统运行情况复杂，不仅用户使用的计算机环境千变万化，包括用户的各种操作方式或各种不同的输入数据，容易引起一些特定用户环境下的问题，在系统实际应用中，数据量很大，从而引起强度或负载问题。
9）由于通信端口多，存取和加密手段的矛盾性等，会造成系统的安全性或适用性等问题
10）新技术的采用，可能涉及技术或者系统兼容的问题，事先没有考虑到。
团队工作：
1）系统需求分析时对客户的需求理解不清楚，或者和用户的沟通存在一些困难。
2）不同阶段的开发人员相互理解不一致。例如，软件设计人员对需求分析的理解有偏差，编程人员对系统设计规格说明书某些内容重视不够，或存在误解。
3）对于设计或编程上一些假定或依赖性，相关人员没有充分沟通
4）项目组成员技术水平参差不齐，新员工较多，或者培训不够等原因也容易引起问题
技术问题：
1）算法错误：在给定条件下没能给出正确或准确的结果
2）语法错误：对于编译性语言程序，编译器可以发现这类问题；但对于解释型语言程序，只能在测试运行时发现
3）计算和精度问题：计算的结果没有满足所需要的精度
4）系统结构不合理，算法选择不科学，造成系统性能低下
5）接口参数传递不匹配，导致模块集成出现问题
项目管理问题：
1）缺乏质量文化，不重视质量计划，对质量、资源、任务、成本等的平衡性把握不好，容易挤掉需求分析、评审、测试等时间，遗留的缺陷会比较多。
2）系统分析时客户的需求不是十分清楚，或者和用户的沟通存在一些困难。
3）开发周期短，需求分析，设计、编程、测试等各项工作不能完全按照定义好的流程来进行，工作不够充分，结果也就不完整、不准确，错误较多；周期短，还给各类开发人员造成太大的压力，引起一些人为的错误
4）开发流程不完善，存在太多的随机性和缺乏严谨的内审或评审机制，容易产生问题
5）文档不完善，风险估计不足等
8.云原生的相关概念：
1）服务化原则：通过服务化架构拆分不同生命周期的业务单元，实现业务单元的独立迭代，从而加快整体的迭代速度，保障迭代的稳定性。同时，服务化架构采用的是面向接口的编程方式，增加了软件的复用程度，增强了水平扩展的能力。服务化设计原则还强调在架构层面抽象化业务模块之间的关系，从而帮助业务模块实现服务流量（而非网络流量）的策略控制和治理，而无须关注这些服务是基于何种编程语言开发的。通过微服务，需要将单体应用进一步进行拆分，按照业务边界重新划分成分布式应用，使得应用与应用之间不再直接共享数据，而是通过约定好的契约进行通信，以提高扩展性，业务化垂直扩展（Scale Up），并将微服务水平扩展（Scale Out）
2) 弹性原则：系统部署规模可以随着业务量的变化自动调整大小，而无须根据事先的容量规划准备固定的硬件和软件资源，优秀的弹性能力不仅能够改变企业的IT成本模式，使得企业不用再考虑额外的软、硬件资源成本支持（闲置成本），也能更好地支持业务规模的爆发式扩张，不再因为软、硬件资源储备不足而留下问题。也就是说，弹性原则是指系统部署规模可以根据业务量的变化自动调整大小，而无须根据事先的容量规划准备固定的硬件和软件资源。
3）可观测性原则：强调主动性，在云计算这样的分布式系统重，主动通过日志、链路跟踪和度量等手段，让一次App点击产生的多次服务调用耗时，返回值和参数都清晰可见，甚至可以下钻到每次第三方软件调用，sql请求，节点拓扑、网络响应等信息中。运维、开发和业务人员通过这样的观测能力可以实时掌握软件的运行情况，并获得前所未有的关联分析能力，以便不断优化业务的健康度和用户体验。简言之，可观测性更强调主动性，在云计算这样的分布式系统中，主动通过日志、链路跟踪和度量等手段，让一次APP点击产生的多次服务调用耗时，返回值、参数都可见。
4）韧性原则：韧性原则是指根据软件所依赖的软硬件组件出现异常的时候，软硬件表现出来的抵御能力，这些异常通过包括硬件故障、硬件资源瓶颈（如CPU或者网卡带宽耗尽）、业务流量超出软件设计承受能力，影响机房正常工作的故障或者灾难，所依赖软件发生故障可能造成业务不可用的潜在影响因素，业务上线后，在运行期的大部分时间里，可能还会遇到各种不确定性输入和不稳定依赖的情况，当这些非正常场景出现时，业务需要尽可能的保证服务的质量，满足当前以联网服务为代表的“永远在线”的要求。因此，韧性能力的核心设计理念是面向失败设计，即考虑如何在各种依赖不正常的情况下，减少异常对系统及服务质量的影响并尽快恢复正常。简言之，韧性是指当软件所依赖的软硬件组件出现异常时，软件所表现出来的抵御能力。韧性的原则的实践与常见架构主要包括：服务异步化能力、服务治理能力（重试、限流、降级、熔断、反压）、主从模式、集群模式、多可用区（AZ，Availability Zone）的高可用、单元化、跨区域容灾、异地多活等。
5）自动化原则：通过IaC、GitOps、OAM、Operator和大量自动化交付工具在CI/CD（持续集成/持续交付）流水线中的实践，企业可标准化企业内部的软件交付过程，也可以在标准化的基础上实现自动化，即通过配置数据自描述和面向终态的交付过程，实现整个软件交付和运维的自动化。
6）零信任原则：传统安全架构认为防火墙内的一切都是安全的，而零信任模型假设防火墙边界已经被攻破了，且每个请求都来自于不可信网络，因此每个请求都是需要经过验证的。第一，不能基于IP配置安全策略。第二，身份应该成为基础设施；第三，假设物理边界被攻破，需要严格控制安全半径。
7）架构持续演进原则：云原生架构本身也应该且必须军持续演进的能力，而不是一个封闭式的，被设计后一成不变的架构。特别是在野外高速迭代的时候，更应该考虑如何保证架构演进与业务发展之间的平衡。演进式架构是指软件开发的初始阶段，就可以通过可拓展和松耦合设计，让后续可能发生的变更更加容易，升级性重构的成本更低，并且能够发生在开发实践、发布实践和整体敏捷度等软件生命周期中的任何阶段。
