使用Apache IoTDB进行IoT相关开发的架构设计与功能实现(5)在开始使用IoTDB之前，大家需要首先配置配置文件，为了方便起见，已经有部分重要文件设置了默认配置。总的来说，Apache IoTDB为用户提供三种配置模块:环境配置文件(iotdb-env.bat, iotdb-env.sh)，环境配置项的默认配置文件。用户可以在文件中配置JAVA-JVM的相关系统配置项系统配置文件(iotdb-engine.properties)，iotdb-engine.properties:IoTDB引擎层配置项的默认配置文件。用户可以在文件中配置IoTDB引擎的相关参数，如JDBC服务监听端口(rpc_port)，未排序数据存储目录(unsequence_data_dir)，等等。此外，用户可以配置关于TsFile的信息，例如每次写入磁盘的数据大小(group_size_in_byte)日志配置文件(logback.xml)三个配置项的配置文件位于IoTDB安装目录中:$IOTDB_HOME/conf文件夹。热修改配置为了方便用户，IoTDB服务器为用户提供了热修改功能，即修改中的一些配置参数iotdb engine. Properties并立即将其应用到系统中。在下面描述的参数中，这些参数Effective是trigger支持热修改。触发方式:客户端发送命令load configurationIoTDB服务器。有关客户端的使用，请参见第4章。IoTDB环境配置文件环境配置文件主要用于配置IoTDB服务器运行时的Java环境相关参数，如JVM相关配置。当IoTDB服务器启动时，这部分配置被传递给JVM。用户可以通过查看iotdb-env.sh(或者iotdb-env.bat)文件。每个变量的细节如下:MAX_HEAP_SIZEHEAP_NEWSIZEJMX_LOCALJMX_PORTJMX_IP

使用Apache IoTDB进行IoT相关开发的架构设计与功能实现(4)编码为了提高数据存储的效率，需要在数据写入时对数据进行编码，从而减少磁盘空间的使用量。在写入和读取数据的过程中，可以减少I/O操作中涉及的数据量以提高性能。对于不同类型的数据，IoTDB支持四种编码方法:PLAIN：普通编码是默认的编码模式，即不编码，支持多种数据类型。它具有较高的压缩和解压缩效率，但空间存储效率较低。TS_2DIFF：二阶差分编码更适合对单调递增或递减的序列数据进行编码，不推荐对波动较大的序列数据进行编码。RLE：游程编码更适合存储具有连续整数值的序列，不推荐用于大多数时间具有不同值的序列数据。游程编码也可用于对浮点数进行编码，但必须指定保留的十进制数字。比较适合存储浮点值连续出现、单调递增或递减的序列数据，不适合存储小数点后精度要求高或波动较大的序列数据。GORILLA：GORILLA编码更适合值相近的浮点序列，不建议用于波动较大的序列数据。常规编码常规数据编码更适合编码常规序列递增的数据(例如，每个数据点之间经过的时间相同的时间序列)，在这种情况下，它比TS_2DIFF更好。规则数据编码方式不适合有波动的数据，即不规则数据，此时建议用TS_2DIFF处理。数据类型和编码之间的对应关系前面描述的四种编码适用于不同的数据类型。如果对应关系是错误的，就不能正确地创建时间序列。下表中详细总结了数据类型及其支持的编码之间的对应关系。**数据类型及其支持的编码之间的对应关系**Data TypeSupported EncodingBOOLEANPLAIN, RLEINT32PLAIN, RLE, TS_2DIFF, REGULARINT64PLAIN, RLE, TS_2DIFF, REGULARFLOATPLAIN, RLE, TS_2DIFF, GORILLADOUBLEPLAIN, RLE, TS_2DIFF, GORILLATEXTPLAIN压缩当时间序列按照指定的类型写成二进制数据编码后，IoTDB使用压缩技术对数据进行压缩，进一步提高空间存储效率。虽然编码和压缩都是为了提高存储效率，但编码技术通常只适用于特定的数据类型。例如，二阶差分编码只适用于INT32或INT64数据类型，存储浮点数需要乘以10m才能转换为整数，之后将数据转换为二进制流。压缩方法(SNAPPY)压缩二进制流，因此压缩方法的使用不再受数据类型的限制。IoTDB允许咱们开发者在创建时间序列时指定列的压缩方法，现在主要支持以下两种压缩方法:UNCOMPRESSEDSNAPPY单节点设置大家可以通过sbin文件夹下的启动服务器脚本来启动IoTDB。# Unix/OS X> nohup sbin/start-server.sh >/dev/null 2>&1 &or> nohup sbin/start-server.sh -c -rpc_port >/dev/null 2>&1 &# Windows> sbin\start-server.bat -c -rpc_port "-c "和"-rpc_port "是可选的选项"-c "指定系统配置文件目录选项“-rpc_port”指定rpc端口如果两个选项都指定了，则rpc _端口将覆盖中的rpc_port配置路径

使用Apache IoTDB进行IoT相关开发的架构设计与功能实现(3)接下来我给大家继续介绍一下Apache IoTDB的数据类型和相关用法在显示时间戳时，IoTDB可以支持长类型和日期时间显示类型。日期时间显示类型可以支持用户定义的时间格式。自定义时间格式的语法如下表所示:**自定义时间格式的语法**SymbolMeaningPresentationExamplesGeraeraeraCcentury of era (>=0)number20Yyear of era (>=0)year1996xweekyearyear1996wweek of weekyearnumber27eday of weeknumber2Eday of weektextTuesday; Tueyyearyear1996Dday of yearnumber189Mmonth of yearmonthJuly; Jul; 07dday of monthnumber10ahalfday of daytextPMKhour of halfday (0~11)number0hclockhour of halfday (1~12)number12Hhour of day (0~23)number0kclockhour of day (1~24)number24mminute of hournumber30ssecond of minutenumber55Sfraction of secondmillis978ztime zonetextPacific Standard Time; PSTZtime zone offset/idzone-0800; -08:00; America/Los_Angeles‘escape for textdelimiter‘’single quoteliteral‘相对时间戳相对时间是指相对于服务器时间的时间now()和DATETIME时间。用法如下：Duration = (Digit+ ('Y'|'MO'|'W'|'D'|'H'|'M'|'S'|'MS'|'US'|'NS'))+RelativeTime = (now() | DATETIME) ((+|-) Duration)+**持续时间单位的语法**SymbolMeaningPresentationExamplesyyear1y=365 days1ymomonth1mo=30 days1mowweek1w=7 days1wdday1d=1 day1dhhour1h=3600 seconds1hmminute1m=60 seconds1mssecond1s=1 second1smsmillisecond1ms=1000_000 nanoseconds1msusmicrosecond1us=1000 nanoseconds1usnsnanosecond1ns=1 nanosecond1ns用法如下：now() - 1d2h //1 day and 2 hours earlier than the current server timenow() - 1w //1 week earlier than the current server time数据类型IoTDB一共支持以下6种数据类型：BOOLEAN (布尔型)INT32 (整数型)INT64 (长整数型)FLOAT (单精度浮点)DOUBLE (双精度浮点)TEXT (字符串)时间序列float和double类型可以指定最大点数，如果编码方法为，则为浮点数小数点后的位数RLE或者TS_2DIFF，如果未指定最大点数，系统将使用浮点精度在配置文件中iotdb-engine.properties。对于浮点数据值，数据范围是(MAX_VALUE，整数型。MAX_VALUE)，而不是Float。MAX_VALUE，而max_point_number是19，这是因为Java中函数Math.round(float)的限制。对于双精度数据值，数据范围为(MAX_VALUE，长整数型。MAX_VALUE)，而不是Double。MAX_VALUE，而max_point_number是19，这是因为Java(Long)中函数Math.round(double)的限制，MAX_VALUE=9.22E18。当用户在系统中输入的数据的数据类型与时间序列的数据类型不对应时，系统将报告类型错误。如下所示，二阶差分编码不支持布尔类型：IoTDB> create timeseries root.ln.wf02.wt02.status WITH DATATYPE=BOOLEAN, ENCODING=TS_2DIFFerror: encoding TS_2DIFF does not support BOOLEAN

使用Apache IoTDB进行IoT相关开发的架构设计与功能实现(2)Apache IoTDB中常见的数据模型和术语通过上图我们可以非常清楚的了解到属性的覆盖范围和它们之间的隶属关系，并且根据属性的覆盖范围和它们之间的隶属关系，将其表达为属性层次结构。其层次关系为:power group layer - power plant layer - device layer - sensor layer。其中，ROOT是根节点，传感器层的每个节点称为一个叶节点。在使用IoTDB的过程中，可以用“.”直接连接从根节点到每个叶节点的路径上的属性，从而形成了IoTDB中一个timeseries的名称。例如，图中最左边的路径可以生成一个名为ROOT.ln.wf01.wt01.status 的路径。1.属性层次结构在获得时间序列的名称后，大家就需要根据数据的实际场景和规模来设置存储组。在一般场景下，数据通常是以组为单位到达的(即数据可能跨越电场和设备)，为了避免写数据时频繁切换io，也为了满足用户对以组为单位的数据进行物理隔离的要求，可以在组层设置存储组。接下来我给大家介绍几个IoTDB中涉及的模型的基本概念：设备设备是真实场景中装备有传感器的装置。在IoTDB中，所有的传感器都应该有相应的设备。传感器传感器是实际场景中的检测设备，能够感知待测信息，并将感知到的信息转换成电信号或其他所需形式的信息输出，并发送给IoTDB。在IoTDB中，所有存储的数据和路径都以传感器为单位进行组织。存储组存储组用于让用户定义如何组织和隔离磁盘上不同的时间序列数据。属于同一存储组的时间序列将被连续写入相应文件夹中的同一文件。该文件可能由于用户命令或系统策略而关闭，因此来自这些传感器的下一个数据将存储在同一文件夹的新文件中。属于不同存储组的时间序列存储在不同的文件夹中。用户可以将任何前缀路径设置为存储组。假设有四个时间序列root.vehicle.d1.s1, root.vehicle.d1.s2, root.vehicle.d2.s1, root.vehicle.d2.s2，两个设备d1和d2在小路下面root.vehicle可能属于同一个车主或者同一个厂家，所以d1和d2关系密切。此时，可以将前缀path root.vehicle指定为一个存储组，这将使IoTDB能够将其下的所有设备存储在同一个文件夹中。下新添加的设备root.vehicle也将属于该存储组。其中完整路径(root.vehicle.d1.s1如上例所示)不允许设置为存储组。设置合理数量的存储组可以带来性能的提升:既不会因为存储文件或文件夹过多而导致IO频繁切换，也不会因为占用大量内存，导致内存文件频繁切换而导致系统变慢，也不会因为存储文件或文件夹过少而导致写命令阻塞，起到降低并发的作用。用户应该根据自己的数据大小和使用场景来平衡存储文件的存储组设置，以获得更好的系统性能。(大家如果对于存储组设置非常感兴趣的话，可以自己查询一下官方提供的存储组规模和性能测试报告)。其中时间序列的前缀必须属于一个存储组。在创建时间序列之前，用户必须设置该序列属于哪个存储组。只有设置了存储组的时间序列才能保存到磁盘上。一旦前缀路径被设置为存储组，就不能更改存储组设置。设置存储组后，不允许再次设置相应前缀路径的所有父层和子层(例如，在root.ln设置为存储组、根层和root.ln.wf01不允许设置为存储组。路径在IoTDB中，路径是符合以下约束的表达式:path: LayerName (DOT LayerName)+LayerName: Identifier | STAR我们称两条路径之间的中间部分为“.”作为一个层，因此root.A.B.C是一条有四层的路径。值得注意的是，在路径中，root是一个保留字符，只允许出现在下面提到的时间序列的开头。如果root出现在其他层中，则无法对其进行解析并报告错误。时间序列路径timeseries路径是IoTDB中的核心概念。时间序列路径可以被认为是产生时间序列数据的传感器的完整路径。IoTDB中的所有时间序列路径必须以root开始，以传感器结束。时间序列路径也可以称为完整路径。例如，如果车辆类型的设备1有一个名为sensor1的传感器，则其时间序列路径可表示为:root.vehicle.device1.sensor1.其中当前IoTDB支持的timeseries路径的层数必须大于等于四层(以后会改为两层)。前缀路径前缀路径是指timeseries路径的前缀所在的路径。前缀路径包含以该路径为前缀的所有时间序列路径。例如，假设我们有三个传感器:root.vehicle.device1.sensor1, root.vehicle.device1.sensor2, root.vehicle.device2.sensor1，前缀路径root.vehicle.device1包含两个时间序列路径root.vehicle.device1.sensor1和root.vehicle.device1.sensor，期间root.vehicle.device2.sensor1被排除在外。带星形的路径为了更方便快捷地表示多个时序路径或前缀路径，IoTDB为用户提供了路径指针。*可以出现在路径的任何一层。根据所处的位置*出现时，带有星号的路径可以分为两种类型:*出现在路径的末端；*出现在路径中间；*出现在路径的末尾的时候，它表示(*)+，它是一层或多层*。举个例子，root.vehicle.device1.*表示所有前缀为root.vehicle.device1层数大于或等于4层，如root.vehicle.device1.*，root.vehicle.device1.*.*， root.vehicle.device1.*.*.*等。当...的时候*出现在路径的中间，它代表*本身，即一层。举个例子，root.vehicle.*.sensor1表示前缀为的4层路径root.vehicle后缀是sensor1。在这里我们应该注意：*不能放在路径的开头。路径包含*与前缀路径具有相同的含义，例如，root.vehicle.*和root.vehicle是一样的。时间戳时间戳是产生数据的时间点。它包括绝对时间戳和相对时间戳绝对时间戳IoTDB中的绝对时间戳分为LONG和DATETIME两种(包括DATETIME-INPUT和DATETIME-DISPLAY)。当用户输入时间戳时，他可以使用长类型时间戳或日期时间输入类型时间戳，日期时间输入类型时间戳支持的格式如下表所示:**日期时间输入类型时间戳的支持格式* *Formatyyyy-MM-dd HH:mm:ssyyyy/MM/dd HH:mm:ssyyyy.MM.dd HH:mm:ssyyyy-MM-dd’T’HH:mm:ssyyyy/MM/dd’T’HH:mm:ssyyyy.MM.dd’T’HH:mm:ssyyyy-MM-dd HH:mm:ssZZyyyy/MM/dd HH:mm:ssZZyyyy.MM.dd HH:mm:ssZZyyyy-MM-dd’T’HH:mm:ssZZyyyy/MM/dd’T’HH:mm:ssZZyyyy.MM.dd’T’HH:mm:ssZZyyyy/MM/dd HH:mm:ss.SSSyyyy-MM-dd HH:mm:ss.SSSyyyy.MM.dd HH:mm:ss.SSSyyyy/MM/dd’T’HH:mm:ss.SSSyyyy-MM-dd’T’HH:mm:ss.SSSyyyy.MM.dd’T’HH:mm:ss.SSSyyyy-MM-dd HH:mm:ss.SSSZZyyyy/MM/dd HH:mm:ss.SSSZZyyyy.MM.dd HH:mm:ss.SSSZZyyyy-MM-dd’T’HH:mm:ss.SSSZZyyyy/MM/dd’T’HH:mm:ss.SSSZZyyyy.MM.dd’T’HH:mm:ss.SSSZZISO8601 standard time format这次先给大家介绍到这里，下次再来给小伙伴们介绍时间戳和相对时间戳的数据格式~

使用Apache IoTDB进行IoT相关开发的架构设计与功能实现(1)当今社会，物联网技术的发展带来了许多繁琐的挑战，尤其是在数据库管理系统领域，比如实时整合海量数据、处理流中的事件以及处理数据的安全性。例如，应用于智能城市的基于物联网的交通传感器可以实时生成大量的交通数据。据估计，未来5年，物联网设备的数量将达数万亿。物联网产生大量的数据，包括流数据、时间序列数据、RFID数据、传感数据等。要有效地管理这些数据，就需要使用数据库。数据库在充分处理物联网数据方面扮演着非常重要的角色。因此，适当的数据库与适当的平台同等重要。由于物联网在世界上不同的环境中运行，选择合适的数据库变得非常重要。1.什么是IoTDB有的小伙伴可能不了解什么是IoTDB，我先来给大家简单介绍一下：IoTDB即物联网数据库，是一个面向时间序列数据的集成数据管理引擎，可以为用户提供特定的数据收集、存储和分析服务。由于其轻量级结构、高性能和可用特性，以及与Hadoop和Spark ecology的紧密集成，IoTDB满足了物联网工业领域的海量数据集存储、高速数据输入和复杂数据分析的要求。2.IoTDB的体系结构IoTDB套件可以提供真实情况下的数据采集、数据写入、数据存储、数据查询、数据可视化和数据分析等一系列功能，下图显示了IoTDB套件的所有组件带来的整体应用程序架构。如图所示呢，咱们广大用户可以使用JDBC将设备上传感器收集的时间序列数据导入本地/远程IoTDB。这些时间序列数据可以是系统状态数据(如服务器负载和CPU内存等)。消息队列数据、来自应用程序的时间序列数据或数据库中的其他时间序列数据。用户也可以将数据直接写入TsFile(本地或HDFS)。对于写入IoTDB和本地TsFile的数据，大家可以使用TsFileSync工具将TsFile同步到HDFS，从而在Hadoop或Spark数据处理平台上实现异常检测、机器学习等数据处理任务。对于写入HDFS或本地TsFile的数据，用户可以使用TsFile-Hadoop-Connector或TsFile-Spark-Connector来允许Hadoop或Spark处理数据。分析的结果可以用同样的方式写回TsFile。还有呢，IoTDB和TsFile提供了客户端工具，完全可以满足用户以SQL形式、脚本形式和图形形式编写和查看数据的各种需求。3.IoTDB的体系特征灵活部署IoTDB为用户提供了云上一键安装工具、一次解压即可使用的终端工具以及云平台与终端工具之间的桥梁工具(数据同步工具)。存储成本低IoTDB可以达到很高的磁盘存储压缩比，这意味着IoTDB可以用更少的硬件磁盘成本存储同样多的数据。高效的目录结构IoTDB支持来自智能网络设备的复杂时间序列数据结构的高效组织，来自同类设备的时间序列数据的组织，海量复杂时间序列数据目录的模糊搜索策略。高吞吐量读写IoTDB支持上百万低功耗设备的强连接数据访问，支持上面提到的智能联网设备和混合设备的高速数据读写。丰富的查询语义IoTDB支持跨设备和传感器的时间序列数据的时间对齐、时间序列域的计算(频域变换)和时间维度丰富的聚合函数支持。容易上手IoTDB支持类SQL语言、JDBC标准API和易于使用的导入/导出工具。自身和开源生态系统紧密集成IoTDB支持Hadoop、Spark等。分析生态系统和Grafana可视化工具。4.IoTDB的文件类型在IoTDB中呢，需要存储的数据种类繁多。现在我来给大家介绍IoTDB的数据存储策略，方便大家对IoTDB的数据管理有一个直观的了解。首先呢，IoTDB存储的数据分为三类，即数据文件、系统文件和预写日志文件。(1)数据文件数据文件存储用户写入IoTDB的所有数据，IoTDB包含TsFile和其他文件。TsFile存储目录可以用data_dirs来配置相关项目，其他文件通过其他特定的数据来配置项目。为了更好地支持用户的磁盘空间扩展等存储需求，IoTDB支持多种文件目录存储方式进行TsFile存储配置。用户可以将多个存储路径设置为数据存储位置，大家可以指定或自定义目录选择策略。(2)系统文件系统文件包括模式文件，模式文件存储IoTDB中数据的元数据信息。它可以通过配置base_dir配置项目。(3)预写日志文件预写日志文件存储WAL文件。它可以通过配置wal_dir配置项目。(4)设置数据存储目录的示例为了更清楚地理解配置数据存储目录，我在这给出一个示例。存储目录设置中涉及的所有数据目录路径有:base_dir、data_dirs、multi_dir_strategy、wal_dir，分别指系统文件、数据文件夹、存储策略、预写日志文件。配置项的示例如下:base_dir = $IOTDB_HOME/datadata_dirs = /data1/data, /data2/data, /data3/datamulti_dir_strategy=MaxDiskUsableSpaceFirstStrategywal_dir= $IOTDB_HOME/data/wal这段代码并不复杂，相信很多小伙伴都应该可以看懂，我在这里给大家简单说明一下下，设置以上配置后，系统将:将所有系统文件保存在＄io TDB _ HOME/data中将TsFile保存在/data1/data、/data2/data、/data3/data中。选择策略是MaxDiskUsableSpaceFirstStrategy，即每次数据写入磁盘时，系统会自动选择剩余磁盘空间最大的目录来写入数据。将WAL数据保存在$IOTDB_HOME/data/wal中这次先为大家介绍到这，下次我再来给小伙伴们分享之前我自己的IoTDB学习经历~

软件可变性的相关思考（一）作者：陈星亮（华为云开天aPaaS专家）软件可变性（Software Variability）是指在一定上下文中一个软件系统被有效改变（扩展、配置、调整）的能力。在许多软件系统的开发运行阶段乃至整个生命周期中，软件可变性都是其设计开发者所要面对的基本问题。       在大多数系统中，可变性表现为软件在某个或某些可变点处对变体的绑定。其中可变点是指软件中可以发生变化（绑定变体）的位置，而变体则是变化发生时，人或机器可以在相应位置做出的选择。       可以看出，在软件的运行实例中，变化发生的位置、变化发生的程度是在设计阶段预定义的。而这种定义又在很大程度上依赖于软件的需求分析以及在此基础上做出的种种假设。系统虽然具有变体绑定能力来满足既定的需求，但可变性模型（可变点、变体以及它们之间的关系）本身没有变化，导致软件在应对变化的需求或环境时存在一定限制。       在传统意义上，软件运行时可变性模型被认为是静态的。在许多研究工作中，模型被以只读的方式访问，以支持软件适应外部的环境。人们将注意力集中在可变性绑定方面（即为什么（重新）绑定变体、绑定什么变体、怎样绑定），而忽视了对运行时可变性模型本身蕴含的限制的突破。随着计算机技术的发展进步、用户需求的增多及变化的加快、系统驻留环境的开放、外界对系统灵活性和可伸缩性要求的提高，这种限制显得愈加突出。       针对软件可变性，开发者们根据软件实现要求和成本投入，采取软件预留配置点、动态软件产品线、运行时可变性动态绑定、多变非核心功能的快速开发等方法来应对。1、软件预留配置点：软件预留配置点可以自动地根据环境的变化来调整自身。换言之，它可以收集和分析有关环境的信息，基于分析的结果决定是否改变自己的行为，如果是，再采取调整动作。系统设计者指出或假设系统所面对环境变化等信息，确定系统所能够感知和收集的环境数据，进而以一定的数据结构将其表示在计算机内，而后才能设计相应的算法对这些信息进行分析并做出决策。在执行环节对于自身的调整，实际上是软件在可变点处对于变体的动态绑定，这是其运行时可变性的表现。关键点：1）设计者难以在系统部署运行之前设想所有的需求或环境的变化，当超过预期的变化出现时，已经成型的系统无法自动地收集与其相关的信息。2）并未改变可变性要素的数量、属性或关系。只能在设计开发时预定的范围内，进行选择。2、动态软件产品线：动态软件产品线包括一组核心资产和从资产开发而来的一系列具有共同特征的软件产品。与传统软件产品线对比，动态软件产品线更关注软件的运行时可变性，本质上是建立具备可配置能力的一系列软件。关键点：1）产品线自身的设计者可以快速开发出具有运行时可变性的软件产品，并赋予其自主选择绑定变体的能力。2）其关注的运行时可变性大部分都是封闭的而非开放的，这意味着运行时可变性应对的是开发者在设计期设想的环境变化，导致软件产品难以应对超过预期的环境变化。3、运行时可变性动态绑定运行时可变性动态绑定机制描述一个运行中的软件如何在一个可变点绑定相应的变体，是软件可变性实现的核心。绑定机制涉及对构件内部结构和行为的调整，包括对子构件的重配置和动态绑定。关键点：1） 对构件行为的调整往往通过重新组织构件的工作流或是重新设置构件内部参数来实现。2） 对于突破了原有设计范围内的变化，需要能被系统识别，并自动生成对应的逻辑。4、多变非核心功能的快速开发为应对行业应用不断变化的情况，亦有思路是降低软件应用开发的难度，将软件的稳定的核心功能与多变的功能分开。对于多变非核心功能，以提供低码开发的方式，便于开发者能快速的根据诉求，进行近场快速开发并投入使用。关键点：1） 软件设计者需要能识别出稳定的核心功能、多变的非核心功能。并且能够在两者之间建立好连接。2） 提供便捷的工具，使得多变的非核心功能能够被近场开发者，甚至是使用者自己能快速实现。如何提升软件的可变性，让软件能够从容应对业务的变化，一直都是软件工程领域的一个重要话题。针对上述4种在应对软件可变性经常用到的方法，各自都有其特点，分别在不同的场景下使用。

关于华为云开天集成工作台，有很多疑问？什么是流？什么是工作流、业务流、集成流？什么是流处理、流编排……这么多问号，头都要大了？！别急，往下看，关于流程模式那些难懂的词儿，在这儿全搞懂！流程（Process）流程图（Flowchart）1.流程（基本流程）图，又称程序框图，是算法、工作流或流程的一种框图表示，它以不同类型的框代表不同种类的步骤，每两个步骤之间则以箭头连接。2.流程图大都有2种符号：①步骤，通常称作“活动”，常以长方形来表示；②决定，常以钻石形来表示。控制流程（Control Flow）1.控制流程（也称为流程控制）是电脑运算领域的用语，意指在程序执行时，个别的指令（或是陈述、子程序）执行或求值的顺序。2.编程语言所提供的流程控制指令一般可以分为以下几种：继续执行位在不同位置的一段指令（无条件分支指令）。若特定条件成立时，执行一段指令，例如C语言的switch指令，是一种有条件分支指令。执行一段指令若干次，直到特定条件成立为止，例如C语言的for指令，仍然可视为一种有条件分支指令。执行位在不同位置的一段指令，但完成后会继续执行原来要执行的指令，包括子程序、协程（coroutine）及计算续体（continuation）。停止程序，不执行任何指令（无条件的终止）。控制流图（Control Flow Chart）利用数学中图的表示方式，标示计算机程序执行过程中所经过的所有路径。控制流图中的每个顶点都对应一个程式基本块，也就是一段没有分支指令、也没有分支目的的程式码，基本块的开始是分支目的，而基本块会以分支为结束。控制流程中会用有向边来表示分支。 工作流（Workflow）工作流是对工作流程及其各操作步骤之间业务规则的抽象、概括描述。工作流建模，即将工作流程中的工作如何前后组织在一起的逻辑和规则，在计算机中以恰当的模型表达并对其实施计算。工作流要解决的主要问题是：为实现某个业务目标，利用计算机在多个参与者之间按某种预定规则自动传递文档、信息或者任务。A workflow consists of an orchestrated and repeatable pattern of activity, enabled by the systematic organization of resources into processes that transform materials, provide services, or process information. It can be depicted as a sequence of operations, the work of a person or group, the work of an organization of staff, or one or more simple or complex mechanisms.业务流程（Business Process）“一系列结构化的、可度量的活动，设计它的目标是为特定客户或市场产生规定的输出。”“一种活动的集合，具有一种或多种输入和确定的输出，这些输出对客户产生价值。”“业务过程是为产生产品或服务而设计的一系列步骤。多数的过程（……）跨越职能，贯穿组织机构图上矩形之间的空白。一些过程的结果是由组织外的客户所接受的产品或服务，称为主要过程；另一些过程的产出不为外部客户所见，但是有效管理所必须的，称为支持过程。”“互相连接的活动集合，它们将输入转换为输出。理想情况下，在过程中发生的转换将为输入增加价值，并形成对接受者更有效用的输出，无论接受者处于上游还下游。”可界定性：必须清晰地定义其边界、输入和输出。顺序：构成过程的活动，必须在时间和空间里具有确定的顺序。客户：过程的结果必须有接收者——客户。增值：在过程中发生的转换必须为接收者增加价值，无论接收者是在过程的上游还是下游。嵌入性：过程不能自己单独存在，它必定嵌入在组织结构中。跨越职能：过程通常但非必须跨越多个职能。“业务过程”的意义更一般化，学术讨论中使用较多；“业务流程”的意义更具体，更倾向于指称具体的活动与任务的流，使用上更大众化。业务流程模型和标记法（BPMN, Business Process Model and Notation）最初由业务流程管理倡议组织（BPMI, Business Process Management Initiative）开发，名称为"Business Process Modeling Notation"，即“业务流程建模标记法”。BPMI于2005年与对象管理组织（OMG, Object Management Group）合并。2011年1月OMG发布2.0版本，同时改为现在的名称。BPMN的目标是，通过提供一套既符合业务人员直观又能表现复杂流程语义的标记法，同时为技术人员和业务人员从事业务流程管理提供支持。四种基本要素：流对象（Flow Object）: 事件（Events），活动（Activities），网关（Gateways）连接对象（Connecting Objects）: 顺序流（Sequence Flow），消息流（Message Flow），关联（Association）泳道（Swimlanes）: 池（Pool），道（Lane）器物（Artifacts/Artefacts）: 数据对象（Data Object），组（Group），注释（Annotation）数据流、数据流程图（Data Flow Diagram）1.      数据流或数据流程是一种软件范式，该范式的主要思想是把处理过程划分为可并行执行的子阶段（流水线），数据流又可以称为流处理（Stream Process）或反应式编程（Reactive Programming）。2.      数据流图或数据流程图。数据流图是描述系统中数据流程的一种图形工具，它标志了一个系统的逻辑输入和逻辑输出，以及把逻辑输入转换逻辑输出所需的加工处理。3.      数据流图不是传统的流程图，数据流也不是控制流。数据流图是从数据的角度来描述一个系统。数据流程编程（Dataflow Programming）数据流程编程是一种编程范式，它将程序建模为数据在运算（Operation）之间流动的有向图，从而实现了数据流程原理和架构。数据流程编程语言，共享了纯函数式语言的某些特征，比如单赋值，并且开发它们的动因，通常是为了向更适合数值处理的语言，增加函数式编程概念。传统上，程序被建模为，按照特定次序发生的一系列运算；这称为指令式编程，这种编程方式也叫做顺序式、过程式、控制流程（意指程序选择某个特定路径）。程序聚焦于命令，符合于冯·诺伊曼的顺序式编程愿景，而数据通常是“静止的”（在上下文）。与之相对，数据流程编程强调了数据的流动（输入输出），并将程序建模为一系列的连接。显式的定义输入和输出的连接运算，它的功能类似于黑箱。一个运算在它的所有输入成为有效时立即运行。因此，数据流程语言是天然并行的，并可在大型的、去中心化的系统上运作。流处理（Stream Processing）流处理(Stream Processing)是一种计算机编程范型，相当于数据流程编程，事件流处理，和反应式编程，其允许一些应用更容易地利用了有限形式的并发处理。这些应用程序可以使用多个计算单元，而无需明确管理这些单元之间的分配，同步或通信。流处理通过限制可执行的并发计算来简化并发软件和硬件。给定一个数据序列（流处理），一系列操作（内核函数）被应用到流中的每个元素。基于流程编程（Flow Based Programming）基于流程（flow-based）的编程，缩写为FBP，是一种编程范型，它将应用定义为黑箱进程的网络，它们经过预先定义的连接，通过消息传递来交换数据，而这里的连接是在“外部”指定给进程的。这些黑箱进程不需要更改内部，就可以无尽的重新连接而形成不同的应用。FBP因而是天然基于构件的。FBP是一种特殊形式的数据流程编程，它基于了有界缓冲区，带有确定生存时间的信息包，命名端口，和独立的连接的定义。端口向FBP提供了构件重用功能，使得FBP成为基于构件的架构。集成流（Integration Flow）数据流的一种，用于企业集成的场景，聚焦于企业应用间集成。企业集成架构模式定义了一组可复用组件，支持灵活连接组装为目标企业应用集成流程。集成流强调从源应用（EndPoint）触发（Construct），经过中间处理（Channel、Routing、Transformation），送达目的应用（Endpoint），是在企业集成领域总结出的架构范式。资料来源：[1]https://baike.baidu.com/item/%E6%B5%81%E7%A8%8B/31013?fr=aladdin[2]https://zh.wikipedia.org/wiki/%E6%B5%81%E7%A8%8B%E5%9B%BE[3]https://zh.wikipedia.org/wiki/%E6%8E%A7%E5%88%B6%E6%B5%81%E7%A8%8B[4]https://zh.wikipedia.org/wiki/%E6%8E%A7%E5%88%B6%E6%B5%81%E7%A8%8B[5]https://zh.wikipedia.org/wiki/%E5%B7%A5%E4%BD%9C%E6%B5%81%E6%8A%80%E6%9C%AF[6]https://en.wikipedia.org/wiki/Workflow[7]https://zh.wikipedia.org/wiki/%E4%B8%9A%E5%8A%A1%E8%BF%87%E7%A8%8B[8]https://zh.wikipedia.org/wiki/%E4%B8%9A%E5%8A%A1%E6%B5%81%E7%A8%8B%E6%A8%A1%E5%9E%8B%E5%92%8C%E6%A0%87%E8%AE%B0%E6%B3%95[9]https://zh.wikipedia.org/wiki/%E8%B3%87%E6%96%99%E6%B5%81%E7%A8%8B%E5%9C%96[10]https://zh.wikipedia.org/wiki/%E6%95%B0%E6%8D%AE%E6%B5%81%E7%A8%8B%E7%BC%96%E7%A8%8B[11]https://zh.wikipedia.org/wiki/%E4%B8%B2%E6%B5%81%E8%99%95%E7%90%86[12]https://zh.wikipedia.org/wiki/%E5%9F%BA%E4%BA%8E%E6%B5%81%E7%A8%8B%E7%BC%96%E7%A8%8B[13]https://www.enterpriseintegrationpatterns.com/patterns/messaging/

1.请问华为云CodeCheck服务可以发现哪些架构设计的问题？架构问题对应的检测规则是什么？ 架构问题对应的检测规则如何查看？2.请问华为云CodeCheck服务，与开源工具Sonar的本质区别是什么？

架构设计分享

       系统架构设计的出发点是帮助系统的用户使用现代化手段完成各项工作，其本质是“业务流程”，而不是一个计算机系统或者计算机应用。       在这一原则之下，普遍系统整个业务功能的设计和实现通常采用SOA（面向服务的体系架构），充分保证系统功能和流程实现的灵活性和扩展性。

>摘要：在云原生2.0阶段，我们到底需要构建一个什么样的架构？华为云首席架构师为你一一解答。本文分享自华为云社区[《华为云首席架构师独家分享：云原生2.0架构设计的8大关键趋势》](https://bbs.huaweicloud.com/blogs/314122?utm_source=csdn&utm_medium=bbs-ex&utm_campaign=other&utm_content=content)，作者：技术火炬手。 云原生2.0是企业智能升级新阶段，企业的云化从“ON Cloud”走向“IN Cloud”，当一切应用都生于云，长于云，云架构的迭代也会进入一个新的阶段。 围绕云原生2.0，**华为云首席架构师顾炯炯提出了8个关键模式：** 分布式云，混合调度，应用驱动基础设施，存算分离与数据治理自动化，可信、平民化DevOps，基于软总线的异构集成，多模态可迭代AI模型，全方位立体式云安全。 # 分布式云 随着云化和数字化渗透到制造类、工业互联网类场景，5G技术在to B领域应用的快速成熟，以及物联网 、AI技术的成熟，现在云的服务对象不仅是企业的后台IT支撑系统，它延伸到了前端的“现场”，类似于工业场景里的近场计算。如果还是将所有的数字化应用系统都放在集中的数据中心，它的时延无法满足实时生产系统的要求。 另外，有一些行业的敏感数据不能从现场或者数据产生地直接简单的上传到云端，它存在数据安全、隐私保密的问题。再比如医疗里的基因大数据、视频监控等场景，如果所有数据都上传到云端，带宽的成本非常高昂。 所以，我们必须要**引入云边端协同的分布式概念，构建分布式云的架构。** 这个架构可以和核心侧架构配合，覆盖核心区域、热点区域、本地机房、业务现场等不同接入时延敏感度，数据隐私合规要求及数据上云带宽成本的应用上云场景。 举个例子，通过这样的方式，可以把云端的很多算力和计算逻辑，甚至是训练好的AI模型推送到更加靠近用户数据产生地的位置上，进行就近的计算，将海量的数据做一定的收敛、分析、脱敏等，再发送到云端进行闭环的处理和控制反馈。 # 混合调度 在很多算法专家的努力下，华为云通过瑶光调度平台大大提高了资源的分配效率，达到甚至超过了80~90%的程度，已经接近于业界的领先水平。但是资源的实际利用率仍然处在一个比较低的水平，当然业界平均也不是特别理想，领先者差不多20%左右。为了解决这样的问题，**华为云引入混合调动、柔性计算的能力，将在线和离线的不同优先级的业务，进行QoS感知的智能调用，实现资源利用率最大化。** 柔性计算不仅仅具备弹性的特征，保证了横向的资源扩展，而且它也能实现纵向资源规格的可大可小。目前，消费者云已经在内部验证了柔性计算的能力，可以在不改变上层业务的前提下提高利用率，实现性能的倍增。关于柔性计算的更多内容参考 华为云首席架构师顾炯炯：[敢为人先，探索架构创新之路如何走。](https://bbs.huaweicloud.com/blogs/314131) # 应用驱动的基础设施 如今，软硬件的垂直整合，特别是靠近操作系统底层的硬件和云服务基础设施层的服务软件之间的纵向整合能力，成为新的趋势，它把基础设施服务底层的硬件和相应的服务封装层打包在一起。 云服务厂商可以设计研发定制芯片，比如存储和网络的硬件卸载的芯片、匹配深度学习逻辑处理框架的芯片等等。如果有能力构建这样的软硬件垂直整合的能力，就能拥有相比其他云服务商更优的价格优势，也得以呈现自身独特的硬件、芯片优势。 有了应用驱动的基础设施之后，**根据应用的性能SLA需求，来定义是使用与软件完全解耦的通用硬件资源，还是匹配应用场景特殊诉求的软硬件深度协同的卸载卡或异构计算资源。** 这也能发挥华为软硬件兼长的优势，我们在硬件领域有不少核心创新：**一个是 SDI**， 叫软件驱动的基础设施，也就是把分布式存储\分布式网络，还有Hypervisor的一些系统能力从服务器卸载到PCI卡上，也即SDI/擎天卸载卡。二是**鲲鹏硬件支撑云存储和数据湖的处理**， 鲲鹏单核处理能力虽弱于X86，但核密度则达到X86 CPU的2倍，因此在对IO及内存带宽作为其性能瓶颈的大数据及分布式存储场景，是比X86更好的选择。同时，我们也在用自研的**昇腾NPU取代GPU构建AI平台**， 它在深度学习的训练推理中体现出更高的能效比。 # 存算分离和数据治理的自动化 未来企业的所有的数据孤岛都将汇聚到云端的数据湖，进行统一生命周期的治理和管理，所以必须要解决数据计算分析的资源需求。数据湖里有各种各样的结构化、半结构化、非结构化的数据，**但这些数据的分析计算和底层的存储容量之间的需求，并不是线性匹配的关系。** 比如对于深度学习的场景，数据量需要不断的计算迭代，它需要更多的计算能力，相对较少的存储需求。因此在不同的业务场景下，数据分析计算和存储的要求是不一样的，最终一定要走向存算分离。 在存算分离领域里面，华为云已经积累优势，从最早的去中心化的分布式存储引擎FusionStorage开始，七年磨一剑，我们从内部验证到向外部的推广，从块存储延伸到对象存储、文件存储、分布式的集群数据库，把原先在开源架构里五花八门的底层存储技术引擎架构实现了统一。经过实际的测试，在业界同样支持存算分离数据湖架构的云场景中，华为云体现了领先30-60%以上性能优势。 **再就是数据治理自动化。** 现在的数据治理的还是人力密集型工作，整个过程非常低效，很难满足很多行业的要求。所以在这个架构模式里面，除了存算分离的数据库，还要构建数据治理自动化。 通过引入AI的技术，将数据的获取、清洗以及最终数据知识的提取，主题库的建立、数据目录的发布，都实现完全的自动化。用户只需要指定入湖的数据源和所属业务主题域，系统自动化创建入湖任务，底层资源根据入湖数据量自动扩缩容，智能完成入湖数据的安全等级、分级分类、隐私等级等数据标签的自动识别打标。这个能力对企业数据资产的快速沉淀能力的构建是至关重要的。 # 可信、平民化DevOps **通过将一系列安全可信措施嵌入到敏捷开发运维模式，** 构建所谓的DevSecOps流水线，实现敏捷快速迭代与严格质量管控兼顾；并**通过低代码/无代码实现更多行业应用资产的沉淀**， 将行业应用的开发效率再上一个新台阶。 Devops实现了应用的敏捷开发，但在面向政企时，还需要满足应用质量和安全可信的要求。因此在遵循DevOps的同时，将安全能力集成到其中，升级成为DevSecOps。使用安全左移、默认安全、运行时安全、安全服务自动化/自助化、基础设施即代码（IaC）等技术， 实现管理与协同、设计与开发、CI/CD、应用管理、运维、安全可信等各个环节的一体化趋势。 此外，由于传统政企开发投入有限，需要通过低码化无码化，来实现对应用进行快速构建及改造。华为云低代码平台AppCube可支持多种页面类型和丰富的组件能力，基于它的服务能力编排和业务流程无代码定制，可实现灵活流程触发方式、多种权限配置方式、自定义业务编排等。 # 基于软件总线的异构集成 即帮助企业**构建可平滑演进的IT架构**， 实现老旧应用与新建云原生应用，线上与线下应用的平滑融合集成。 云原生下，企业很多应用都要进行微服务解耦，遵从微服务的治理架构，进行水平扩展的架构的设计，甚至把原来的单体架构逐步进行拆解。但这个过程不是一蹴而就的，尤其是那些包袱比较重的传统行业，他们还面临很多现实的挑战。所以我们要在企业传统IT架构和云原生架构之间搭建无缝的桥梁，在确保企业业务连续性最大化的前提下，实现平滑的切换和演进。 以Roma Connect为例，它可以通过软总线的形式，把云原生和非云原生的传统世界无缝的连接起来，支持异构的应用和数据库源的对接，也可以对接到云上开发平台、数据湖，实现无缝互通。 在架构的平滑演进中，首先需要将传统非云原生应用封装为REST接口与云原生应用对接，通过统一接口服务层APIC进行开放，业务云原生应用通过标准接口即可获取老系统信息。同样的机制可以将线上线下，及部署在多云环境上企业IT系统的无缝互通。 其次传统Oracle/Sybase等传统数据库及中间件与设备协议接入上云：云上云原生应用通过云上标准API调用、数据库访问、消息订阅等方式即可获取传统数据。 最后，通过全生命周期的API管理能力，包含从设计、发布、上架、治理的全过程，帮助企业构建整个跨地域，跨组织、跨部门的应用网络，并沉淀行业应用资产。 # 多模态可迭代的AI模型 AI在行业落地面临的问题是能够获取到的训练数据是非常有限的，单纯的依赖数据驱动的深度学习训练，使得行业AI模型是非常难以泛化、通用化。 预训练大模型是解决AI应用开发定制化和碎片化的重要方法。 通过一个AI大模型实现在众多场景通用、泛化和规模化复制，减少对数据标注的依赖，赋能AI开发由作坊式转变为工业化开发，比如华为云之前推出的盘古大模型。 另外也要**引入知识计算的能力**， 类似于把知识图谱这样的能力和基于感知计算的数据驱动的AI模型互补结合起来。也就是说把知识模型和数据模型，在数据样本相对缺少的情况下结合在一起，更好服务于行业AI的落地。帮助企业打造自己的知识计算平台，整合分散在不同系统、多种形态的企业数据，形成带有建议性的知识体系。 # 全方位的立体式云安全 1.0阶段的云安全服务更多的是孤立的安全能力：虚拟化安全，hyporvisor防逃逸能力，云防火墙能力其实都是割裂的，并没有跟所有的云服务形成互锁。 **全方位的立体式运营安全通过打通离散的云安全服务能力，将其与其他云服务及客户应用形式互锁**， 构建安全Build-in的云原生应用，以及引入可信智能计算，解决跨行业数据隐私保护与流通碰撞、价值挖掘之间的矛盾。 首先通过可信智能计算提供四个核心能力，进行安全可信的数据计算。包括： 1、跨组织、跨行业的多方数据融合分析和多方横向与纵向联邦学习建模； 2、支持对接主流数据源和深度学习框架； 3、支持安全多方计算（例如同态加密，差分隐私等），并支持用户自定义隐私策略； 4、基于区块链的数据计算轨迹的可追溯可审计。 此外，为了全方位安全，还需要将全栈云（及其子集）下沉部署（连线/非连线），彻底解决敏感行业上云安全顾虑，以及将全栈云服务、企业新开发云原生应用、aPaaS/SaaS等与全栈云安全能力互锁，为用户构建体系化的云安全平台。

项目背景:用户通过域名访问vip, nginx做为负载均衡为后端应用分发请求, 后端应用为dubbo服务,存储分为redis和mysql. redis做为持久会存储数据库,支持前端业力. 并且通过mq同步数据到mysql,供后端使用. 同时后台写mysql也要通过mq同步到redis.目前后端服务qps最高可以达到5万,本次架构设计在不重构的情况下短期内最快的方法达到目标10万qps.架构方案:一，现有idc架构可支撑5万qps。这是经过一年考验下来的，可做为保底的；如果应用全部上云，需要从0开始重新验证能否达到现有5万qps，再去验证能否达到10万qps，时间等未知风验很大；  二，10万qps目标，建议用简单粗暴的方式，直接把idc应用层架构复制一套上云；不建议在现有架构上继续调优，现在架构如果不重构，可能很难找到问题；与其这样不如把人力时间用到另一个方向，比如数据中心；   三，由idc+公有云两套系统构成混合云模式，数据统一使用idc的redis和mysql，公有云与idc 的数据库连接建立专线；混合云的方式可以检测公有云的实际性能，也能为将来全部迁移公有云提供真实参考；   四，平时比赛，使用idc架构完全可以支撑，公有云留少量机器和用户请求预热，重要比赛，临时增加云资源扛突发，服务器成本节约，扩展性也灵活；   五，公有云都有出现过大规模事故,造成全站不能访问的情况,为了保险，我们依然要保留idc的服务，所以混合云也许是最适合的；      技术难点：   一，如何将用户请求分流到 idc和公有云两套应用   1，域名解析两条A记录，分别指向idc和公有云两个vip，通过dns平均分配用户请求   2，idc架构在nginx前端增加四层负载均衡（lvs,ha_porxy），由四层负载均衡将用户请求转发给idc的nginx和公有云的负载均衡，lvs与公有云通信通过专线；   二，前端应用入口放大，后端数据中心，需要扩容   1，redis使用多主多从，redis3.0 还是用 代理（predixy,codis）；   2，业务拆分，组建更多的一主多从；      具体实施：   1，双系统流量分发配置lvs即可，本赛季最好能用上几轮，演练资源增减，熟悉流程，检测可行性；   2，redis数据中心需要大量的测试，选型，可做重点研究（这也是目前急需解决的单点）；

我们还可能出于统计原因来选择深度模型。任何时候，当我们选择一个特定的机器学习算法时，我们隐含地陈述了一些先验，这些先验是关于算法应该学得什么样的函数的。选择深度模型默许了一个非常普遍的信念，那就是我们想要学得的函数应该涉及几个更加简单的函数的组合。这可以从表示学习的观点来解释，我们相信学习的问题包含发现一组潜在的变差因素，它们可以根据其他更简单的潜在的变差因素来描述。或者，我们可以将深度结构的使用解释为另一种信念，那就是我们想要学得的函数是包含多个步骤的计算机程序，其中每个步骤使用前一步骤的输出。这些中间输出不一定是变差因素，而是可以类似于网络用来组织其内部处理的计数器或指针。根据经验，更深的模型似乎确实在广泛的任务中泛化得更好 (Bengio et al., 2007b; Erhan et al., 2009; Bengio, 2009; Mesnil et al., 2011; Ciresan et al., 2012; Krizhevsky et al., 2012a; Sermanet et al., 2013; Farabet et al., 2013; Couprie et al., 2013; Kahou et al., 2013; Goodfellow et al., 2014d; Szegedy et al., 2014a)。展示了一些实验结果的例子。这表明使用深层架构确实在模型学习的函数空间上表示了一个有用的先验。

开源数据库架构设计原则01. 技术选型选择成熟的平台和技术，同时是最熟悉的，能做到极致的，用好不用坏，用熟不用生。目前业界的MySQL主流分支版本有Oracle官方版本的MySQL、Percona Server、MariaDB。02. 高可用选择高可用解决方案探讨的本质上是低宕机时间解决方案，可以理解成高可用的反面是不可用，绝大部分情况下数据库宕机才会导致数据库不可用。随着技术发展，开源数据库方面很多高可用组件（主从复制、半同步、MGR、MHA、Galera Cluster）,对应场景，只有适合的，没有万能的，需要理解每个高可用优缺点。03. 表设计表设计方面目前一致坚持和提倡的原则：单表数据量所有表都需要添加注释，单表数据量建议控制在 3000 万以内不保存大字段数据不在数据库中存储图片、文件等大数据表使用规范拆分大字段和访问频率低的字段，分离冷热数据单表字段数控制在 20 个以内索引规范1.单张表中索引数量不超过 5 个2.单个索引中的字段数不超过 5 个3.INNODB 主键推荐使用自增列，主键不应该被修改，字符串不应该做主键，如果不指定主键，INNODB 会使用唯一且非空值索引代替4.如果是复合索引，区分最大的字段放在索引前面5. 避免冗余或重复索引：合理创建联合索引（避免冗余）6. 不在低基数列上建立索引，例如‘性别'7. 不在索引列进行数学运算和函数运算字符集utf8mb4(偏生字，表情符)04. 优化原则                    05. 复制方式MySQL复制方式提供异步方式、半同步方式、全局事务强一致性、binglog同步。需要不同业务系统间 或 两个数据库间进行同步。异步方式可以防止故障和效率问题的蔓延，扩大化；但强一致性会更复杂，并发、事务大小都有求限制06. 分离原则区分核心的业务，重要业务，渠道，内部业务的业务系统，对不同的系统设置不同的架构。为核心业务设置 最佳为分库，多活 专用高速公路，其他业务可以做读写分离，缓存。07. 扩展性对于系统来说扩展性很重要，尽量做到水平扩展。避免过度依赖纵向扩展，同时具备纵向，横向扩展的能力，例如无状态应用应该多套负载均衡多活部署，数据库分库架构。08. 读写分离读多写少场景（10%写 90%读）复制存在延迟，业务对延迟不敏感的实现方式：                    1. 通过应用代码配置读写分离，                    2. 通过中间代理方式路由只读库                     3. 业务和数据库为一个单位09. 分库分表当表中数据记录的数量超过3000万条，再好的索引也已经不能提高数据查询的速度，这时需要将表拆分成更多的小表，增加性能，增加弹性，避免发生垮库进行操作。引入中间价要考虑性能代价,聚合需求。分库原则尽量在app 上层进行分库，就是流量。分多少合适：可用性和性能满足TPS。路由：写入配置文件 或则 插表 或则 zookeeper。10. 归档原则历史数据定期进行归档 或则 移到其他大数据平台。能让轻量级数据库更多缓存有用的数据。在MySQL分区表里 注意要避免分区锁，只能写读的场景。11. 连接池的要求长链接，自动重链，延时和异常记录， 弹性链接，检测满，异常告警，进阶要求是记录所有访问情况，可以扩展出很多能力。应用和数据库连接池设置，数据库允许的连接数设置，常见问题。A ）应用的数据库连接池设置偏小，一旦数据库相应慢（新上线应用，缺少索引 等）则应。用排队严重，甚至雪崩，而遗憾的是数据库能力还远为用尽。B ）不具备失效及时发现和重新链接数据库能力。C ）隔离级别设置：RR 和 RC下不同的表现。12. 应用解耦通过应用访问数据库而不是直接访问，重要业务不能依赖低保障级别的系统，应用层重要业务和普通业务解耦，关键业务要独立。13. 组件失效免疫能力单一应用，单一硬件，甚至单一基础设施，单一站点容灾，业务影响，故障恢复能力，要季度级别进行演练。14. 关键词组件减负特别是数据库访问,数据库成本最高，扩展性最难，可用性保障最难，恢复难度和时间最大。减负：能不用就不用，使用最简单，成本最低的语句，避免大事务，慎用两阶段事务。15. 灰度数据库减少发布时变更数据库对全局的影响,只有应用程序灰度是不够的，还要有专门的灰度数据库。在分库、读写分离架构下，一套含数据库的完整应用架构，变的很自然。所为灰度环境就是生产环境，生产数据，所影响的也是生产环境，只是范围比测试环境更广，更真实。其实就是小范围的生产环境。类似于游戏内测。16. 高仿真架构体系建立高仿真架构体系数据库，操作系统升级：应用是否适应，性能会变好， 还是变坏应用上线发布，系统变更（列如换平台），提前判断业务影响和性能瓶颈应对突发交易量，例如双十一，性能极限在哪里，瓶颈在哪里。17. 容灾保障高可用是运维核心要求，容灾是最后屏障例如 双活比单活好，MGR比复制架构好，重要系统要做好高可用，容灾建设。18. 多中心建设冗余是基础，多中心建设是为了提升容灾能力和扩展能力，并保障业务。19. 应用和数据库是一个整体应用和运维人员一起，解决应用解耦，数据库解耦，追账补数，业务监控，应用路由，故障切换等。可用性，效率，故障恢复等方面都要一起参与。20. 性能提升开源数据库使用应该合理且有效的结合周边的其他类型数据库，做到性能最大化。比如：Redis、MongoDB、ES、ClickHouse等。总结1. 最适合的架构是结合软件特性和业务场景，又能取得成本收益平衡；2. 大数据情况下可以是利用读写分离、分库分表，但要选择合适的；3. 不适合分库的应该考虑竭尽所能把核心库做小，然后通过垂直扩展来扩容；4. 用尽各种技术， 高可用 和 容灾手段保证其可用。

1、什么是架构和架构本质在软件行业，对于什么是架构，都有很多的争论，每个人都有自己的理解。 此君说的架构和彼君理解的架构未必是一回事。我们主要针对互联网服server系统（类似网站）来定义架构：架构是系统的骨架，支撑和链接各个部分，包括组件、连接件、约束规范，以及指导这些内容设计与演化的原理。组件：类似应用服务，独立模块、数据库、nginx等等、连接件：分布式调用、进程间调用、调用使用http协议还是tcp协议、组件之间的交互关系、约束规范： 定规则做限制：例如设计原则、编码规范等等。是系统性地思考，权衡利弊之后在现有资源约束下的“最合理决策”，并由它来指导团队中的每个人思想层面上的一致。即架构=组件+交互。这类似建筑设计规划，城市总体规划等，其实就是架构，只是应用的场景不同。盖一座小房子，可以拍脑袋干起来，但是当你要盖一座大楼，如果没有一个建筑设计规划，可以想象搭理最后是什么样？架构的本质就是对系统进行有序化地重构以致符合当前业务的发展，并可以快速扩展。那什么样的系统要考虑做架构设计?1. 需求相对复杂.2. 非功能性需求在整个系统占据重要位置.3. 系统生命周期长,有扩展性需求.4.系统基于组件或者集成的需要.5.业务流程再造的需要. 2、架构分类架构可细分为业务架构、应用架构、技术架构, 代码架构, 部署架构,.业务架构是战略，应用架构是战术，技术架构是装备。其中应用架构承上启下，一方面承接业务架构的落地，另一方面影响技术选型。熟悉业务，形成业务架构，根据业务架构，做出相应的应用架构，最后技术架构落地实施。如何针对当前需求，选择合适的应用架构，如何面向未来，保证架构平滑过渡，这个是软件开发者，特别是架构师，都需要深入思考的问题。一、业务架构（俯视架构）：包括业务规划，业务模块、业务流程，对整个系统的业务进行拆分，对领域模型进行设计，把现实的业务转化成抽象对象。没有最优的架构，只有最合适的架构，一切系统设计原则都要以解决业务问题为最终目标，脱离实际业务的技术情怀架构往往会给系统带入大坑，任何不基于业务做异想天开的架构都是耍流氓。所有问题的前提要搞清楚我们今天面临的业务量有多大，增长走势是什么样，而且解决高并发的过程，一定是一个循序渐进逐步的过程。 合理的架构能够提前预见业务发展1~2年为宜。这样可以付出较为合理的代价换来真正达到技术引领业务成长的效果。看看京东业务架构（网上分享图）：二、应用架构（剖面架构，也叫逻辑架构图）：硬件到应用的抽象，包括抽象层和编程接口。应用架构和业务架构是相辅相成的关系。业务架构的每一部分都有应用架构。类似：应用架构：应用作为独立可部署的单元，为系统划分了明确的边界，深刻影响系统功能组织、代码开发、部署和运维等各方面. 应用架构定义系统有哪些应用、以及应用之间如何分工和合作。这里所谓应用就是各个逻辑模块或者子系统。应用架构图关键有2点：1、职责划分: 明确应用（各个逻辑模块或者子系统）边界1）逻辑分层2）子系统、模块定义。3）关键类。2、职责之间的协作：1）接口协议：应用对外输出的接口。2）协作关系：应用之间的调用关系。应用分层有两种方式：一种是水平分（横向），按照功能处理顺序划分应用，比如把系统分为web前端/中间服务/后台任务，这是面向业务深度的划分。另一种是垂直分（纵向），按照不同的业务类型划分应用，比如进销存系统可以划分为三个独立的应用，这是面向业务广度的划分。应用的合反映应用之间如何协作，共同完成复杂的业务case，主要体现在应用之间的通讯机制和数据格式，通讯机制可以是同步调用/异步消息/共享DB访问等，数据格式可以是文本/XML/JSON/二进制等。应用的分偏向于业务，反映业务架构，应用的合偏向于技术，影响技术架构。分降低了业务复杂度，系统更有序，合增加了技术复杂度，系统更无序。应用架构的本质是通过系统拆分，平衡业务和技术复杂性，保证系统形散神不散。系统采用什么样的应用架构，受业务复杂性影响，包括企业发展阶段和业务特点；同时受技术复杂性影响，包括IT技术发展阶段和内部技术人员水平。业务复杂性（包括业务量大）必然带来技术复杂性，应用架构目标是解决业务复杂性的同时，避免技术太复杂，确保业务架构落地。三、代码架构（也叫开发架构）：子系统代码架构主要为开发人员提供切实可行的指导，如果代码架构设计不足，就会造成影响全局的架构设计。比如公司内不同的开发团队使用不同的技术栈或者组件，结果公司整体架构设计就会失控。代码架构主要定义：一、代码单元:1、配置设计2、框架、类库。二、代码单元组织：1、编码规范，编码的惯例。2、项目模块划分3、顶层文件结构设计，比如mvc设计。4、依赖关系四、技术架构，也可以叫系统架构技术架构：确定组成应用系统的实际运行组件（lvs，nginx，tomcat，php-fpm等），这些运行组件之间的关系，以及部署到硬件的策略。技术架构主要考虑系统的非功能性特征，对系统的高可用、高性能、扩展、安全、伸缩性、简洁等做系统级的把握。系统架构的设计要求架构师具备软件和硬件的功能和性能的过硬知识，这也是架构设计工作中最为困难的工作。五、部署拓扑架构图（实际物理架构图）：拓扑架构，包括架构部署了几个节点，节点之间的关系，服务器的高可用，网路接口和协议等，决定了应用如何运行，运行的性能，可维护性，可扩展性，是所有架构的基础。这个图主要是运维工程师主要关注的对象。3、应用架构架构演进路程：->初始阶段：LAMP,部署在一台服务器->应用服务器和数据服务器分离->使用缓存改善性能->使用集群改善并发->数据库地读写分离->使用反向代理和cdn加速->使用分布式文件和分布式数据库->业务拆分->分布式服务业务架构是生产力，应用架构是生产关系，技术架构是生产工具。业务架构决定应用架构，应用架构需要适配业务架构，并随着业务架构不断进化，同时应用架构依托技术架构最终落地。企业一开始业务比较简单，比如进销存，此时面向内部用户，提供简单的信息管理系统（MIS），支持数据增删改查即可，单体应用可以满足要求。随着业务深入，进销存每块业务都变复杂，同时新增客户关系管理，以更好支持营销，业务的深度和广度都增加，这时需要对系统按照业务拆分，变成一个分布式系统。更进一步，企业转向互联网+战略，拓展在线交易，线上系统和内部系统业务类似，没必要重做一套，此时把内部系统的逻辑做服务化改造，同时供线上线下系统使用，变成一个简单的SOA架构。紧接着业务模式越来越复杂，订单、商品、库存、价格每块玩法都很深入，比如价格区分会员等级，访问渠道（无线还是PC），销售方式（团购还是普通）等，还有大量的价格促销，这些规则很复杂，容易相互冲突，需要把分散到各个业务的价格逻辑进行统一管理，以基础价格服务的方式透明地提供给上层应用，变成一个微内核的SOA架构。同时不管是企业内部用户，还是外部顾客所需要的功能，都由很多细分的应用提供支持，需要提供portal，集成相关应用，为不同用户提供统一视图，顶层变成一个AOA的架构（application orientated architecture）。4、衡量架构的合理性架构为业务服务，没有最优的架构，只有最合适的架构， 架构始终以高效，稳定，安全为目标来衡量其合理性。一、稳定性。指标：1. 高可用：要尽可能的提高软件的可用性，我想每个操作人都不愿意看到自己的工作无法正常进行。黑盒白盒测试、单元测试、自动化测试、故障注入测试、提高测试覆盖率等方式来一步一步推进。二、高效指标：1. 文档化：不管是整体还是部分的整个生命周期内都必须做好文档化，变动的来源包括但不限于BUG，需求。2. 可扩展：软件的设计秉承着低耦合的理念去做，注意在合理的地方抽象。方便功能更改、新增和运用技术的迭代，并且支持在适时对架构做出重构。3. 高复用：为了避免重复劳动，为了降低成本，我们希望能够重用之前的代码、之前的设计。这点对于架构环境的依赖是最大的。三、安全指标1. 安全：组织的运作过程中产生的数据都是具有商业价值的，保证数据的安全也是刻不容缓的一部分。以免出现XX门之类丑闻。加密、https等为普遍手段5、常见架构误区误区1——架构专门由架构师来做，业务开发人员无需关注：架构的再好，最终还是需要代码来落地，并且组织越大这个落地的难度越大。不单单是系统架构，每个解决方案每个项目也由自己的架构，如分层、设计模式等。如果每一块砖瓦不够坚固，那么整个系统还是会由崩塌的风险。所谓“千里之堤，溃于蚁穴”。误区2——架构师确定了架构蓝图之后任务就结束了：架构不是“空中楼阁”，最终还是要落地的，但是架构师完全不去深入到第一线怎么知道“地”在哪？怎么才能落的稳稳当当。误区3——不做出完美的架构设计不开工：世上没有最好架构，只有最合适的架构。我们需要的不是一下子造出一辆汽车，而是从单轮车 --> 自行车 --> 摩托车，最后再到汽车。想象一下2年后才能造出的产品，当初市场还存在吗？6、架构知识体系架构演进初始阶段：LAMP,部署在一台服务器应用服务器和数据服务器分离使用缓存改善性能使用集群改善并发数据库地读写分离使用反向代理和cdn加速使用分布式文件和分布式数据库业务拆分分布式服务架构模式分层：横向分层：应用层，服务层，数据层分割：纵向分割：拆分功能和服务分布式分布式应用和服务分布式静态资源分布式数据和存储分布式计算集群：提高并发和可用性缓存：优化系统性能cdn方向代理访问资源本地缓存分布式缓存异步：降低系统的耦合性提供系统的可用性加快响应速度冗余：冷备和热备，保证系统的可用性自动化：发布，测试，部署，监控，报警，失效转移，故障恢复安全：架构核心要素高性能：网站的灵魂性能测试前端优化应用优化数据库优化可用性：保证服务器不宕机，一般通过冗余部署备份服务器来完成负载均衡数据备份自动发布灰度发布监控报警伸缩性：建集群，是否快速应对大规模增长的流量，容易添加新的机器集群负载均衡缓存负载均衡可扩展性：主要关注功能需求，应对业务的扩展，快速响应业务的变化。是否做法开闭原则，系统耦合依赖分布式消息服务化安全性：网站的各种攻击，各种漏洞是否堵住，架构是否可以做到限流作用，防止ddos攻击。xss攻击sql注入csr攻击web防火墙漏洞安全漏洞ssl7、架构书籍推荐1. 《大型网站技术架构：核心原理与案例分析》这是比较早，比较系统介绍大型网站技术架构的书，通俗易懂又充满智慧，即便你之前完全没接触过网站开发，通读前几章，也能快速获取到常见的网站技术架构及其应用场景。非常赞。2. 《亿级流量网站架构核心技术》相比《大型网站技术架构》的高屋建瓴，开涛的这本《亿级流量网站架构核心技术》则落实到细节，网站架构中常见的各种技术，比如缓存、队列、线程池、代理……，统统都讲到了，而且配有核心代码。甚至连 Nginx 的配置都有！如果你想在实现大流量网站时找参考技术和代码，这本书最合适啦。3. 《架构即未来》这是一本“神书”啦，超越具体技术层面，着重剖析架构问题的根源，帮助我们弄清楚应该以何种方式管理、领导、组织和配置团队。4. 《分布式服务架构：原理、设计与实战》这本书全面介绍了分布式服务架构的原理与设计，并结合作者在实施微服务架构过程中的实践经验，总结了保障线上服务健康、可靠的最佳方案，是一本架构级、实战型的重量级著作。5. 《聊聊架构》这算是架构方面的一本神书了，从架构的原初谈起，从业务的拆分谈起，谈到架构的目的，架构师的角色，架构师如何将架构落地……强烈推荐。不过，对于没有架构实践经验的小伙伴来讲，可能会觉得这本书比较虚，概念多，实战少。但如果你有过一两个项目的架构经验，就会深深认同书中追本溯源探讨的架构理念。6. 《软件架构师的12项修炼》大多数时候所谓的“技术之玻璃天花板”其实只是缺乏软技能而已。这些技能可以学到，缺乏的知识可以通过决定改变的努力来弥补。