华为云用户手册

Aggregate模型 以实际的例子来说明什么是聚合模型，以及如何正确的使用聚合模型。 示例1：导入数据聚合 假设业务有以下模式： 表1 参数说明 ColumnName Type AggregationType Comment user_id LARGEINT - 用户 ID date DATE - 数据导入日期 city VARCHAR(20) - 用户所在城市 age SMALLINT - 用户年龄 sex TINYINT - 用户性别 last_visit_date DATETIME REPLACE 用户最后一次访问时间 cost BIGINT SUM 用户总消费 max_dwell_time INT MAX 用户最大停留时间 min_dwell_time INT MIN 用户最小停留时间 转换成建表语句，如下所示。 CREATE TABLE IF NOT EXISTS demo.example_tbl ( `user_id` LARGEINT NOT NULL COMMENT "用户id", `date` DATE NOT NULL COMMENT "数据灌入日期时间", `city` VARCHAR(20) COMMENT "用户所在城市", `age` SMALLINT COMMENT "用户年龄", `sex` TINYINT COMMENT "用户性别", `last_visit_date` DATETIME REPLACE DEFAULT "1970-01-01 00:00:00" COMMENT "用户最后一次访问时间", `cost` BIGINT SUM DEFAULT "0" COMMENT "用户总消费", `max_dwell_time` INT MAX DEFAULT "0" COMMENT "用户最大停留时间", `min_dwell_time` INT MIN DEFAULT "99999" COMMENT "用户最小停留时间" ) AGGREGATE KEY(`user_id`, `date`, `city`, `age`, `sex`) DISTRIBUTED BY HASH(`user_id`) BUCKETS 1 PROPERTIES ( "replication_allocation" = "tag.location.default: 1" ); 可以看到，这是一个典型的用户信息和访问行为的事实表。在一般星型模型中，用户信息和访问行为一般分别存放在维度表和事实表中。这里我们为了更加方便的解释Doris的数据模型，将两部分信息统一存放在一张表中。 表中的列按照是否设置了AggregationType，分为Key（维度列）和Value（指标列）。没有设置AggregationType的，如user_id、date、age、sex称为Key，而设置了AggregationType的称为Value。 当导入数据时，对于Key列相同的行会聚合成一行，而Value列会按照设置的AggregationType进行聚合。AggregationType目前有以下四种聚合方式： SUM：求和，多行的Value进行累加。 REPLACE：替代，下一批数据中的Value会替换之前导入过的行中的Value。 MAX：保留最大值。 MIN：保留最小值。 表2 原始数据 user_id date city age sex last_visit_date cost max_dwell_time min_dwell_time 10000 2017-10-01 A 20 0 2017-10-01 06:00:00 20 10 10 10000 2017-10-01 A 20 0 2017-10-01 07:00:00 15 2 2 10001 2017-10-01 A 30 1 2017-10-01 17:05:45 2 22 22 10002 2017-10-02 B 20 1 2017-10-02 12:59:12 200 5 5 10003 2017-10-02 C 32 0 2017-10-02 11:20:00 30 11 11 10004 2017-10-01 D 35 0 2017-10-01 10:00:15 100 3 3 10004 2017-10-03 D 35 0 2017-10-03 10:20:22 11 6 6 我们假设这是一张记录用户访问某商品页面行为的表。我们以第一行数据为例，解释如下： 表3 参数说明 数据 说明 10000 用户id，每个用户唯一识别id 2017-10-01 数据入库时间，精确到日期 A 用户所在城市 20 用户年龄 0 性别男（1 代表女性） 2017-10-01 06:00:00 用户本次访问该页面的时间，精确到秒 20 用户本次访问产生的消费 10 用户本次访问，驻留该页面的时间 10 用户本次访问，驻留该页面的时间（冗余） 那么当这批数据正确导入到Doris中后，Doris中最终存储如下： 表4 插入数据 user_id date city age sex last_visit_date cost max_dwell_time min_dwell_time 10000 2017-10-01 A 20 0 2017-10-01 07:00:00 35 10 2 10001 2017-10-01 A 30 1 2017-10-01 17:05:45 2 22 22 10002 2017-10-02 B 20 1 2017-10-02 12:59:12 200 5 5 10003 2017-10-02 C 32 0 2017-10-02 11:20:00 30 11 11 10004 2017-10-01 D 35 0 2017-10-01 10:00:15 100 3 3 10004 2017-10-03 D 35 0 2017-10-03 10:20:22 11 6 6 可以看到，用户10000只剩下了一行聚合后的数据。而其余用户的数据和原始数据保持一致。这里先解释下用户10000 聚合后的数据： 前5列没有变化，从第6列 last_visit_date 开始： 2017-10-01 07:00:00：因为last_visit_date列的聚合方式为REPLACE，所以2017-10-01 07:00:00替换了2017-10-01 06:00:00保存了下来。 在同一个导入批次中的数据，对于REPLACE这种聚合方式，替换顺序不做保证。如在这个例子中，最终保存下来的，也有可能是2017-10-01 06:00:00。而对于不同导入批次中的数据，可以保证，后一批次的数据会替换前一批次。 35：因为cost列的聚合类型为SUM，所以由20+15累加获得35。 10：因为max_dwell_time列的聚合类型为MAX，所以10和2取最大值，获得10。 2：因为min_dwell_time列的聚合类型为MIN，所以10和2取最小值，获得2。 经过聚合，Doris中最终只会存储聚合后的数据。换句话说，即明细数据会丢失，用户不能够再查询到聚合前的明细数据了。 示例2：保留，明细数据。 接示例1，将表结构修改如下： 表5 参数说明 ColumnName Type AggregationType Comment user_id LARGEINT - 用户 ID date DATE - 数据导入日期 timestamp DATETIME - 数据导入时间，精确到秒 city VARCHAR(20) - 用户所在城市 age SMALLINT - 用户年龄 sex TINYINT - 用户性别 last_visit_date DATETIME REPLACE 用户最后一次访问时间 cost BIGINT SUM 用户总消费 max_dwell_time INT MAX 用户最大停留时间 min_dwell_time INT MIN 用户最小停留时间 即增加了一列timestamp，记录精确到秒的数据导入时间。 同时，将AGGREGATE KEY设置为AGGREGATE KEY(user_id, date, timestamp, city, age, sex)。 导入数据如下： 表6 原始数据 user_id date timestamp city age sex last_visit_date cost max_dwell_time min_dwell_time 10000 2017-10-01 2017-10-01 08:00:05 A 20 0 2017-10-01 06:00:00 20 10 10 10000 2017-10-01 2017-10-01 09:00:05 A 20 0 2017-10-01 07:00:00 15 2 2 10001 2017-10-01 2017-10-01 18:12:10 A 30 1 2017-10-01 17:05:45 2 22 22 10002 2017-10-02 2017-10-02 13:10:00 B 20 1 2017-10-02 12:59:12 200 5 5 10003 2017-10-02 2017-10-02 13:15:00 C 32 0 2017-10-02 11:20:00 30 11 11 10004 2017-10-01 2017-10-01 12:12:48 D 35 0 2017-10-01 10:00:15 100 3 3 10004 2017-10-03 2017-10-03 12:38:20 D 35 0 2017-10-03 10:20:22 11 6 6 那么当这批数据正确导入到Doris中后，Doris中最终存储如下： 表7 数据结果 user_id date timestamp city age sex last_visit_date cost max_dwell_time min_dwell_time 10000 2017-10-01 2017-10-01 08:00:05 A 20 0 2017-10-01 06:00:00 20 10 10 10000 2017-10-01 2017-10-01 09:00:05 A 20 0 2017-10-01 07:00:00 15 2 2 10001 2017-10-01 2017-10-01 18:12:10 A 30 1 2017-10-01 17:05:45 2 22 22 10002 2017-10-02 2017-10-02 13:10:00 B 20 1 2017-10-02 12:59:12 200 5 5 10003 2017-10-02 2017-10-02 13:15:00 C 32 0 2017-10-02 11:20:00 30 11 11 10004 2017-10-01 2017-10-01 12:12:48 D 35 0 2017-10-01 10:00:15 100 3 3 10004 2017-10-03 2017-10-03 12:38:20 D 35 0 2017-10-03 10:20:22 11 6 6 示例3：导入数据与已有数据聚合。 接示例1中的参数列表，插入以下表中数据。 表8 原始数据 user_id date city age sex last_visit_date cost max_dwell_time min_dwell_time 10000 2017-10-01 A 20 0 2017-10-01 07:00:00 35 10 2 10001 2017-10-01 A 30 1 2017-10-01 17:05:45 2 22 22 10002 2017-10-02 B 20 1 2017-10-02 12:59:12 200 5 5 10003 2017-10-02 C 32 0 2017-10-02 11:20:00 30 11 11 10004 2017-10-01 D 35 0 2017-10-01 10:00:15 100 3 3 10004 2017-10-03 D 35 0 2017-10-03 10:20:22 11 6 6 在导入一批新的数据： 表9 新数据 user_id date city age sex last_visit_date cost max_dwell_time min_dwell_time 10004 2017-10-03 D 35 0 2017-10-03 11:22:00 44 19 19 10005 2017-10-03 E 29 1 2017-10-03 18:11:02 3 1 1 那么当这批数据正确导入到Doris中后，Doris中最终存储如下: 表10 user_id date city age sex last_visit_date cost max_dwell_time min_dwell_time 10000 2017-10-01 A 20 0 2017-10-01 07:00:00 35 10 2 10001 2017-10-01 A 30 1 2017-10-01 17:05:45 2 22 22 10002 2017-10-02 B 20 1 2017-10-02 12:59:12 200 5 5 10003 2017-10-02 C 32 0 2017-10-02 11:20:00 30 11 11 10004 2017-10-01 D 35 0 2017-10-01 10:00:15 100 3 3 10004 2017-10-03 D 35 0 2017-10-03 11:22:00 55 19 6 10005 2017-10-03 E 29 1 2017-10-03 18:11:02 3 1 1 可以看到，用户10004的已有数据和新导入的数据发生了聚合。同时新增了10005用户的数据。 数据的聚合，在Doris中有如下三个阶段发生： 每一批次数据导入的ETL阶段。该阶段会在每一批次导入的数据内部进行聚合。 底层BE进行数据Compaction的阶段。该阶段，BE会对已导入的不同批次的数据进行进一步的聚合。 数据查询阶段。在数据查询时，对于查询涉及到的数据，会进行对应的聚合。 数据在不同时间，可能聚合的程度不一致。例如一批数据刚导入时，可能还未与之前已存在的数据进行聚合。但是对于用户而言，用户只能查询到聚合后的数据。即不同的聚合程度对于用户查询而言是透明的。用户需始终认为数据以最终的完成的聚合程度存在，而不应假设某些聚合还未发生。

基础概念 Internal Catalog Doris原有的Database和Table都将归属于Internal Catalog。Internal Catalog是内置的默认Catalog，用户不可修改或删除。 External Catalog 可以通过CREATE CATALOG命令创建一个External Catalog。创建后，可以通过SHOW CATALOGS命令查看已创建的Catalog。 切换Catalog 用户登录Doris后，默认进入Internal Catalog，因此默认的使用和之前版本并无差别，可以直接使用SHOW DATABASES，USE DB等命令查看和切换数据库。 用户可以通过SWITCH命令切换Catalog。如： SWITCH internal; SWITCH hive_catalog; 切换后，可以直接通过SHOW DATABASES，USE DB等命令查看和切换对应Catalog中的Database。Doris会自动通过Catalog中的Database和Table。用户可以像使用Internal Catalog一样，对External Catalog中的数据进行查看和访问。 当前，Doris只支持对 External Catalog中的数据进行只读访问。 删除Catalog External Catalog中的Database和Table都是只读的。但是可以删除Catalog（Internal Catalog无法删除）。可以通过DROP CATALOG命令删除一个External Catalog。 该操作仅会删除Doris中该Catalog的映射信息，并不会修改或变更任何外部数据目录的内容。 Resource Resource是一组配置的集合。用户可以通过CREATE RESOURCE命令创建一个Resource。之后可以在创建Catalog时使用这个Resource。 一个Resource可以被多个Catalog使用，以复用其中的配置。

关于Partition和Bucket的数量和数据量的建议 一个表的Tablet总数量等于 (Partition num*Bucket num)。 一个表的Tablet数量，在不考虑扩容的情况下，推荐略多于整个集群的磁盘数量。 单个Tablet的数据量理论上没有上下界，但建议在1G-10G的范围内。如果单个Tablet数据量过小，则数据的聚合效果不佳，且元数据管理压力大。如果数据量过大，则不利于副本的迁移、补齐，且会增加Schema Change或者Rollup操作失败重试的代价（这些操作失败重试的粒度是Tablet）。 当Tablet的数据量原则和数量原则冲突时，建议优先考虑数据量原则。 在建表时，每个分区的Bucket数量统一指定。但是在动态增加分区时（ADD PARTITION），可以单独指定新分区的Bucket数量。可以利用这个功能方便的应对数据缩小或膨胀。 一个Partition的Bucket数量一旦指定，不可更改。所以在确定Bucket数量时，需要预先考虑集群扩容的情况。比如当前只有3台host，每台host有1块盘。如果Bucket的数量只设置为3或更小，那么后期即使再增加机器，也不能提高并发度。 举一些例子：假设在有10台BE，每台BE一块磁盘的情况下。如果一个表总大小为500MB，则可以考虑4-8个分片。5GB：8-16个分片。50GB：32个分片。500GB：建议分区，每个分区大小在50GB左右，每个分区16-32个分片。5TB：建议分区，每个分区大小在50GB 左右，每个分区16-32个分片。

复合分区与单分区 复合分区。 第一级称为Partition，即分区。用户可以指定某一维度列作为分区列（当前只支持整型和时间类型的列），并指定每个分区的取值范围。 第二级称为Distribution，即分桶。用户可以指定一个或多个维度列以及桶数对数据进行HASH分布或者不指定分桶列设置成Random Distribution对数据进行随机分布。 此场景推荐使用复合分区。 有时间维度或类似带有有序值的维度，可以以这类维度列作为分区列。分区粒度可以根据导入频次、分区数据量等进行评估。 历史数据删除需求：如有删除历史数据的需求（比如仅保留最近N天的数据）。使用复合分区，可以通过删除历史分区来达到目的。也可以通过在指定分区内发送DELET语句进行数据删除。 解决数据倾斜问题：每个分区可以单独指定分桶数量。如按天分区，当每天的数据量差异很大时，可以通过指定分区的分桶数，合理划分不同分区的数据,分桶列建议选择区分度大的列。 单分区。 用户也可以不使用复合分区，即使用单分区。则数据只做Hash分布。

关于Random Distribution的设置以及使用场景 如果OLAP表没有更新类型的字段，将表的数据分桶模式设置为RANDOM，则可以避免严重的数据倾斜（数据在导入表对应的分区的时候，单次导入作业每个batch的数据将随机选择一个tablet进行写入）。 当表的分桶模式被设置为RANDOM时，因为没有分桶列，无法根据分桶列的值仅对几个分桶查询，对表进行查询的时候将对命中分区的全部分桶同时扫描，该设置适合对表数据整体的聚合查询分析而不适合高并发的点查询。 如果OLAP表的是Random Distribution的数据分布，那么在数据导入的时候可以设置单分片导入模式（将load_to_single_tablet设置为true），那么在大数据量的导入的时候，一个任务在将数据写入对应的分区时将只写入一个分片，这样将能提高数据导入的并发度和吞吐量，减少数据导入和Compaction导致的写放大问题，保障集群的稳定性。

基本原理 下图展示了Stream load的主要流程，省略了一些导入细节。 ^ + | | | | 1A. User submit load to FE | | | +--v-----------+ | | FE | 5. Return result to user | +--+-----------+ | | | | 2. Redirect to BE | | | +--v-----------+ +---+Coordinator BE| 1B. User submit load to BE +-+-----+----+-+ | | | +-----+ | +-----+ | | | 3. Distrbute data | | | +-v-+ +-v-+ +-v-+ |BE | |BE | |BE | +---+ +---+ +---+ Stream load中，Doris会选定一个节点作为Coordinator节点。该节点负责接数据并分发数据到其他数据节点。您可以通过HTTP协议提交导入命令。如果提交到FE，则FE会通过HTTP redirect指令将请求转发给某一个BE。用户也可以直接提交导入命令给某一指定BE。导入的最终结果由Coordinator BE返回给用户。

JDBC通过ssl方式连接doris(验证证书) 在应用层进行代码重试和负载均衡时，代码重试需要应用自己多个配置doris前端节点地址。比如发现一个连接异常退出，就自动在其他连接上进行重试。 前提条件：集群必须开启HTTPS。 下载证书请在集群详情页面下载。 在已安装mysql客户端的ecs服务器上先执行以下命令，导入服务器证书。 your_certificate_path：自定义证书存放路径。 your_truststore_name：自定义truststore名称。 your_truststore_password：自定义 truststore密码。 keytool -importcert -alias MySQLCACert -file your_certificate_path -keystore your_truststore_name -storepass your_truststore_password 运行该命令的过程中，需要手动输入yes，如下所示： 图1 运行图 执行以下代码样例。 以下java代码中your_truststore_path为truststore文件路径，your_truststore_password为上述命令设置的truststore密码。 public class Main { private static String URL = "jdbc:mysql:loadbalance://" + "[FE1_host]:[FE1_port],[FE2_host]:[FE2_port],[FE3_host]:[FE3_port]/[your_database]?" + "loadBalanceConnectionGroup=first&ha.enableJMX=true"; static Connection getNewConnection() throws SQLException, ClassNotFoundException { Class.forName("com.mysql.cj.jdbc.Driver"); System.setProperty("javax.net.ssl.trustStore","your_truststore_path"); System.setProperty("javax.net.ssl.trustStorePassword","your_truststore_password"); String user = "your_username"; String password = "your_password"; Properties props = new Properties(); props.setProperty("user", user); props.setProperty("password", password); props.setProperty("useSSL", "true"); props.setProperty("requireSSL", "true"); props.setProperty("verifyServerCertificate", "true"); props.setProperty("sslMode", "VERIFY_CA"); return DriverManager.getConnection(URL, props); } public static void main(String[] args) throws Exception { Connection c = getNewConnection(); try { System.out.println("begin print"); String query = "your sqlString"; c.setAutoCommit(false); Statement s = c.createStatement(); ResultSet resultSet = s.executeQuery(query); while(resultSet.next()) { int id = resultSet.getInt(1); System.out.println("id is: "+id); } System.out.println("end print"); Thread.sleep(Math.round(100 * Math.random())); c.close(); } catch (Exception e) { e.printStackTrace(); } } } 父主题： 通过JDBC方式连接Doris

数据模型选择 Doris数据模型上目前分为三类：AGGREGATE KEY，UNIQUE KEY，DUPLICATE KEY。三种模型中数据都是按KEY进行排序。 Aggregate模型。 Aggregate模型可以通过预聚合，极大地降低聚合查询时所需扫描的数据量和查询的计算量，非常适合有固定模式的报表类查询场景。但是该模型对count( * ) 查询很不友好。同时因为固定了Value列上的聚合方式，在进行其他类型的聚合查询时，需要考虑语意正确性。 Aggregate Key相同时，新旧记录进行聚合，目前支持的聚合函数有SUM，MIN，MAX，REPLACE。 CREATE TABLE site_visit ( siteid INT, city SMALLINT, username VARCHAR(32), pv BIGINT SUM DEFAULT '0' ) AGGREGATE KEY(siteid, city, username) DISTRIBUTED BY HASH(siteid) BUCKETS 10; Unique模型。 Unique模型针对需要唯一主键约束的场景，Unique key相同时，新记录覆盖旧记录，可以保证主键唯一性约束。适用于有更新需求的分析业务。目前Unique key实现上和Aggregate key的 REPLACE聚合方法一样，二者本质上相同。但是无法利用ROLLUP等预聚合带来的查询优势（因为本质是REPLACE，没有SUM这种聚合方式）。 CREATE TABLE sales_order ( orderid BIGINT, status TINYINT, username VARCHAR(32), amount BIGINT DEFAULT '0' ) UNIQUE KEY(orderid) DISTRIBUTED BY HASH(orderid) BUCKETS 10; Duplicate模型。 Duplicate模型相同的行不会合并，适合任意维度的Ad-hoc查询。虽然无法利用预聚合的特性，但是不受聚合模型的约束，可以发挥列存模型的优势（列裁剪、向量执行等）。 CREATE TABLE session_data ( visitorid SMALLINT, sessionid BIGINT, visittime DATETIME, city CHAR(20), province CHAR(20), ip varchar(32), brower CHAR(20), url VARCHAR(1024) ) DUPLICATE KEY(visitorid, sessionid) DISTRIBUTED BY HASH(sessionid, visitorid) BUCKETS 10;

大宽表与Star Schema 业务方建表时, 为了和前端业务适配, 往往不对维度信息和指标信息加以区分, 而将Schema定义成大宽表，这种操作对于数据库其实不是那么友好，我们更建议用户采用星型模型。 Schema中字段数比较多, 聚合模型中可能key列比较多, 导入过程中需要排序的列会增加。 维度信息更新会反应到整张表中，而更新的频率直接影响查询的效率。 使用过程中，建议用户尽量使用Star Schema区分维度表和指标表。频繁更新的维度表也可以放在MySQL外部表中。而如果只有少量更新, 可以直接放在Doris中。在Doris中存储维度表时，可对维度表设置更多的副本，提升Join的性能。

表格存储里面的数据是否可以迁移？ CloudTable使用对象存储服务存储集群数据的备份和快照，实现安全、高可靠和低成本的存储需求，了解更多请参见对象存储服务。如果需要查看账号下建立的桶，参考OBS服务《控制台指南》管理桶章节。 CloudTable使用云数据迁移可以将云上云下或第三方云上的多种数据源的数据迁移到CloudTable集群的HBase表中。详细步骤参见使用CMD迁移数据到CloudTable 父主题： 数据读写类

如何调整数据均衡的灵敏度？ BE定期（每隔一分钟）会向FE汇报一次磁盘使用情况。FE记录这些统计值，并根据这些统计值，限制不同的操作请求。 在FE中分别设置了 高水位（High Watermark）和危险水位（Flood Stage） 两级阈值。危险水位高于高水位。当磁盘使用率高于高水位时，Doris会限制某些操作的执行（如副本均衡等）。而如果高于危险水位，则会禁止某些操作的执行（如导入）。 同时，在BE上也设置了 危险水位（Flood Stage）。考虑到FE并不能完全及时的检测到BE上的磁盘使用情况，以及无法控制某些 BE 自身运行的操作（如 Compaction）。因此BE上的危险水位用于 BE 主动拒绝和停止某些操作，达到自我保护的目的。请参见磁盘空间管理。

设置回收站时间 回收站原理：删除的数据不会直接从磁盘上删除，而是先放入回收站，等待超时时间满足后，再从磁盘上直接删除。 设置回收站时间需要考虑的因素。 回收站时间过长，会累积垃圾文件，占用磁盘空间。 回收站时间过长，调用admin clean trash;命令后，容易导致数据不均衡，触发二次数据均衡，再次产生垃圾文件。 回收站时间过短，容易误删、异常原因导致被删除的tablet无法被恢复。建议根据实际业务，观察回收站占用的磁盘空间的平均值，并根据占用磁盘空间和所需的防误删时间窗口，设置合理时间值。 curl -X POST http://{be_ip}:{be_http_port}/api/update_config?trash_file_expire_time_sec={value}\&persist=true be_host：节点地址。 be_webserver_port：节点端口。 trash_file_expire_time_sec：回收站清理的间隔，72个小时，当磁盘空间不足时，trash下的文件保存期可不遵守这个参数，默认值259200。

如何查看回收站数据 登录CloudTable控制台。 创建Doris集群。 连接Doris集群。 查看回收站数据。 show trash; 图1 回收站数据 恢复回收站数据。 curl -X POST http://{be_host}:{be_webserver_port} /api/restore_tablet?tablet_id={tablet_id}\&schema_hash={schema_hash} be_host：节点地址。 be_webserver_port：节点端口。

通过CCE模板管理页面安装Sermant Injector 第一次启动Sermant Injector实例之前，需申请Sermant Injector https证书。 登录已安装kubectl命令的CCE节点，请参考Linux弹性云服务器登录方式概述选择相应方式登录CCE节点。 执行以下命令申请Sermant Injector https证书： wget -O- https://cse-bucket-cn-east-3.obs.cn-east-3.myhuaweicloud.com/javaagent/certificate.sh | sh 该步骤会把证书挂载到cse命名空间中，如果不存在cse命名空间，则会自动创建。 该步骤会向k8s集群申请名为sermant-injector.cse.svc的CertificateSigningRequest，如果之前存在，则会被覆盖。 该步骤会在cse命名空间中创建名为sermant-injector-secret的Secret，如果之前存在，则会被覆盖。 使用Sermant Injector时，如果提示证书失效等证书相关的错误，请重新申请证书并重新安装Sermant Injector实例。 上传Sermant Injector模板。 下载模板。Sermant Injector模板版本及下载地址如下表所示： 版本 发行时间 获取路径 1.0.9 2023.06.30 sermant-injector-1.0.9.tgz 上传模板，请参考上传模板。 安装Sermant Injector，请参考创建模板实例。 安装时，按需修改配置文件，配置说明如下： agent: image: # 选填配置，Sermant Agent镜像版本，默认为最新版本。 version: ${agent.version} cse: config: # 必填配置，微服务引擎配置中心地址，获取方式请参考获取微服务引擎配置中心地址。 endpoints: https://localhost:30110 registry: # 必填配置，注册中心类型，当前支持SERVICE_COMB/NACOS type: SERVICE_COMB # 必填配置，微服务引擎注册中心地址，获取方式请参考获取微服务引擎服务注册发现地址。 endpoints: https://localhost:30100 image: # 选填配置，镜像拉取策略：Always(总是拉取)/IfNotPresent(本地有则使用本地镜像,不拉取)/Never(只使用本地镜像，从不拉取) pullPolicy: IfNotPresent # 必填配置，CCE所在的region，具体请参考地区和终端节点。 region: ${region} injector: image: # 选填配置，injector镜像版本，默认为最新版本。 version: ${injector.version} # 选填配置，拉取镜像的密钥。 pullSecrets: default-secret # 选填配置，injector实例数，若CCE集群只有一个节点，则需配置为1。 replicas: 2 webhooks: # 必填配置，K8s集群证书，请在已安装kubectl命令的CCE节点中使用以下命令获取 # kubectl config view --raw --minify --flatten -o jsonpath='{.clusters[].cluster.certificate-authority-data}' caBundle: null 目前Sermant Injector只支持安装到cse命名空间中，如果安装时，无法在页面上找到cse命名空间，请刷新页面。 父主题： 安装Sermant Injector

背景信息 CCE容器部署的Spring Cloud应用可通过Sermant Injector插件自动挂载Sermant Agent，通过Sermant Agent接入未开启安全认证的微服务引擎。同Spring Cloud Huawei接入方式相比，Sermant Agent方式无需修改代码即可接入并使用应用注册发现等功能，但是不支持使用微服务治理功能。关于Sermant Agent，请参考Sermant-agent使用手册。 请根据您的实际业务需要选择使用Sermant Agent、Spring Cloud Huawei接入方式中的一种将Spring Cloud应用接入微服务引擎，但不可同时使用，以免导致冲突。

使用条件 已创建Kubernetes类型的环境，请参考创建环境。 环境中已绑定1.15以上版本的CCE集群，请参考绑定CCE集群。 CCE集群节点已安装kubectl，安装kubectl命令请参考通过kubectl连接集群中相关操作。 环境中已纳管2.4.0及以上版本的未开启安全认证的微服务引擎专享版，请参考纳管资源。 Sermant Agent及Sermant Injector版本要求1.0.3及以上。

操作步骤 登录ServiceStage控制台。 单击“全链路流量控制”。 单击待创建基线泳道所在泳道组名称，进入“全链路流量控制”页面。 单击“创建基线泳道”，参考下表填写泳道信息，其中带“*”标志的参数为必填参数。 参数 参数说明 *泳道名称 基线泳道的名称。 *标签 用于在Kubernetes类型的环境下创建并部署组件时，将绑定微服务引擎（对应于微服务引擎CSE服务的ServiceComb引擎专享版）的组件打上相应的标签以标记流量。当有请求访问时，应用网关会根据路由规则将流量转发到对应流量标签的微服务上。当无法找到对应标签的微服务时，将转发至基线泳道对应的微服务。 基线泳道的标签默认为base，不可修改。 单击“确定”，完成基线泳道创建。

操作步骤 登录ServiceStage控制台。 单击“全链路流量控制”。 单击待创建非基线泳道所在泳道组名称，进入“全链路流量控制”页面。 单击“创建泳道”，参考下表填写泳道信息，其中带“*”标志的参数为必填参数。 参数 参数说明 *泳道名称 非基线泳道的名称。 *标签 用于在Kubernetes类型的环境下创建并部署组件时，将绑定微服务引擎（对应于微服务引擎CSE服务的ServiceComb引擎专享版）的组件打上相应的标签以标记流量。当有请求访问时，应用网关会根据路由规则将流量转发到对应流量标签的微服务上。 路由规则 当泳道组流量入口网关路由是基于内容配置时，可设置。 单击切换开关，设置路由规则生效方式。 或：默认生效方式，匹配任意一条路由规则就生效。 且：匹配所有路由规则才生效。 单击“新增匹配规则”，设置路由匹配规则。 匹配类型：支持的路由规则匹配类型。当前仅支持基于“请求头”类型的匹配。 参数名称：“匹配类型”对应的key值。 条件类型：条件值满足的匹配规则，可选择前缀匹配、精确匹配和正则匹配。 条件值：“匹配类型”对应的value值。 单击“确定”，完成非基线泳道创建。

操作步骤 为准备资源时创建的应用网关创建服务来源，请参考创建服务来源。 服务来源参数请参考下表进行设置。 参数名称 参数说明 来源类型 目标服务的来源，选择“CSE ServiceComb引擎”。 来源名称 输入目标服务的名称，例如：servicecomb。 引擎实例 选择准备资源时已经创建的微服务引擎（对应于微服务引擎CSE服务的ServiceComb引擎专享版）。 为准备资源时创建的应用网关绑定目标服务，请参考创建服务。 参考下表填写相关参数。 参数名称 参数说明 来源类型 目标服务的来源，选择“CSE ServiceComb引擎”。 服务来源 选择1输入的目标服务的名称，例如：servicecomb。 环境选择 保持默认。 服务列表 选择创建并部署基线版本组件时已创建的接入了1所选择的微服务引擎后生成的实例“unit-controller”。

操作步骤 登录ServiceStage控制台。 单击“全链路流量控制”。 单击待创建非基线泳道所在泳道组名称（例如：lane-test），进入“全链路流量控制”页面。 单击“创建泳道”，参考下表填写非基线泳道信息。 参数名称 参数说明 *泳道名称 输入非基线泳道的名称，例如：gray。 *标签 输入gray。 用于在Kubernetes类型的环境下创建并部署组件时，将绑定微服务引擎（对应于微服务引擎CSE服务的ServiceComb引擎专享版）的组件打上相应的标签以标记流量。当有请求访问时，应用网关会根据路由规则将流量转发到对应流量标签的微服务上。 单击“确定”，完成非基线泳道创建。

解决方法 待查看日志的主机未安装ICAgent ServiceStage的日志查看能力是由AOM服务提供的。主机是否安装ICAgent是使用AOM的日志能力的前提，否则将无法查看ServiceStage的日志。ICAgent是AOM的采集器，分别运行在每台主机上用于实时采集指标、日志和应用性能数据。 如何为待查看日志的主机安装ICAgent，请参考安装ICAgent。 用户业务日志输出位置为非标准位置 由于用户配置了日志策略，导致用户程序业务日志未输出到标准的输出位置。需参考如下方法进行排查处理： 虚拟机部署 排查配置的日志策略，是否把用户程序业务日志输出位置写到ServiceStage默认指定的虚拟机日志目录（/var/log/application/${组件名}-${环境名}-${随机字符串}/${版本号}/${实例ID}/start_app.log）外的其他目录。 请查询业务代码，对日志策略进行调整。 容器部署 排查配置的日志策略，是否把业务日志输出到出标准输出外的其他地方。请参考设置应用日志策略进行相关配置。

微服务和普通应用有什么不同？ 微服务是一种架构模式，其核心是将一个单体应用分成多个部分进行开发。所以微服务架构的应用程序，其本质上是一个分布式应用。 基于微服务架构构建的应用程序，可以让业务变化更快，整体系统可靠性更高。 类型 微服务 普通应用 开发 每个微服务的体量相对较小，业界的two pizza团队和“2周即可全部重写全部代码”等都可以作为微服务划分的参考。在开发时期，需注意服务接口的定义以与周边微服务进行配合，“基于契约”的开发方式是非常推荐的。 微服务开发，请参考开发微服务应用。 普通应用逻辑复杂、模块耦合、代码臃肿、修改难度大、版本迭代效率低下。 部署 微服务组成的应用系统通常比较复杂，在一次性部署的时候，需要进行编排部署。 微服务应用部署，请参考创建并部署组件。 普通应用可能会比较大，构建和部署时间也相应地比较长，不利于频繁部署，阻碍持续交付。在移动应用开发中，这个问题会显得尤为严重。 运维 在原来的指标监控、日志收集之外还非常强调治理。其核心理念是在运行时期通过对线上系统的各种调整以达到系统整体健康度要求的效果。 应用运维，请参考组件运维。 普通应用线上问题修复周期长，任何一个线上问题修复都需要对整个应用系统进行全面升级。 父主题： 应用开发问题

安全认证概述 开启了安全认证的微服务引擎专享版，通过微服务控制台提供了基于RBAC（Role-Based Access Control，基于角色的访问控制）的系统管理功能。权限与角色相关联，您可以使用关联了admin角色权限的账号创建新账号，根据实际业务需求把合适的角色同账号关联。使用该账号的用户则具有对该微服务引擎的相应的访问和操作权限。 微服务引擎专享版开启了安全认证之后，所有调用的API都需要先获取token才能调用，认证流程请参考服务中心RBAC说明。 开启了安全认证的微服务引擎专享版，在使用安全认证前需要完成以下工作： 创建安全认证账号名和密码 配置微服务安全认证的账号名和密码 框架支持安全认证功能的版本要求：Spring Cloud需要集成Spring Cloud Huawei 1.6.1及以上版本，Java Chassis需要2.3.5及以上版本。 老版本未开启安全认证的微服务引擎专享版，升级到新版本并开启安全认证的场景，请参考管理微服务引擎专享版安全认证。 父主题： 使用安全认证

开发流程说明 开发微服务应用 如果您已经完成了微服务应用的开发，可以跳过本流程，进入准备环境。 进行微服务应用开发，首先需要进行技术选型。技术选型是一个复杂的问题，技术决策者需要考虑使用的技术是否容易被团队成员掌握，技术能否满足项目对于功能、性能、可靠性方面的要求，还需要考虑商业服务等多方面的因素。本文档不探讨技术选型，假设技术团队已经选择了适合自己的开发框架。大部分技术团队都会选择开源框架来构建业务。 开发微服务应用的具体内容，请参考开发微服务应用。 使用Spring Cloud，通常会使用下面的技术进行本地微服务开发： 使用Java Chassis，通常会使用下面的技术进行本地微服务开发： 准备环境 创建云上环境，以支持微服务引擎接入调试、云上应用部署和使用微服务引擎功能。一般情况下，会创建一个测试环境和一个生产环境。通过ServiceStage，能够非常方便的管理云上环境，详细内容请参考准备环境。 对接微服务应用 用于微服务应用对接微服务引擎，涉及到对已经开发好的应用的配置文件、构建脚本的修改。修改完成后，需要对应用重新编译、打包，通过ServiceStage将应用包部署到微服务引擎，详细内容请参考对接微服务应用。 部署微服务应用 开发完成的微服务应用，通过ServiceStage部署到微服务引擎，详细内容请参考部署微服务应用。 使用微服务引擎功能 对于持续发展的应用系统，都会持续完善和迭代，每个迭代可能需要对微服务应用进行更新升级，需要使用更多的微服务引擎功能。持续迭代的功能演进，会重复上面的应用开发、编译、打包和部署环节。详细内容请参考使用微服务引擎功能。

本地开发工具说明 本地开发工具包含了微服务引擎2.x的本地轻量化版本，提供用于本地开发的轻量服务中心、配置中心，和简单易用的界面。 使用说明请参考本地开发工具压缩包中的README.md文件。 表1 本地引擎资源配额限制 功能 资源 最大配额 微服务管理 微服务版本数量（个） 10,000 单个微服务实例数量（个） 100 单个微服务契约数量（个） 500 配置管理 配置数量（个） 600 表2 本地轻量化微服务引擎版本说明 版本 对应微服务引擎版本 发行时间 获取路径 2.1.7 2.x 2023.6.1 Local-CSE-2.1.7-windows-amd64.zip Local-CSE-2.1.7-linux-amd64.zip Local-CSE-2.1.7-linux-arm64.zip 本地轻量化微服务引擎仅作为本地开发调测，请勿用于商业使用。 本地轻量化微服务引擎支持在Windows、Linux系统下使用。 父主题： 附录

开发能力要求 本文档的主要目的就是说明这些开源微服务开发框架如何接入和使用微服务引擎的功能，假设您已经熟悉和掌握如下开发能力： 使用Java语言进行微服务开发。假设您已经基于一种ServiceStage支持的微服务开发框架开发了应用系统，并期望将应用系统托管在微服务引擎上运行。本文档提供微服务应用接入微服务引擎的相关技术支持。开源微服务开发框架如何使用不是本文档的范围，您可以通过开源社区获取相关微服务开发框架的入门材料和开发指南。 理解注册中心、配置中心在微服务应用中的作用，并在项目中搭建和使用注册中心。不同的微服务开发框架默认支持的开源注册中心会有差异，理解注册中心的作用，可以更加容易的更换注册中心。 熟悉应用部署，请参考创建并部署组件。

Java Chassis微服务组件配置安全认证账号名和密码 配置文件配置方式 为微服务的“microservice.yml”文件增加以下配置，若已配置请忽略。 servicecomb: credentials: rbac.enabled: true #结合用户实际值配置 cipher: default account: name: test #结合用户实际配置 password: mima #结合用户实际配置 cipher: default 用户密码password默认为明文存储，无法保证安全。建议您对密码进行加密存储，请参考配置安全认证参数。 环境变量注入方式 为微服务添加如表2所示环境变量。 添加环境变量，请参考管理应用环境变量。 表2 环境变量 环境变量 说明 servicecomb_credentials_rbac_enabled true：开启安全认证。 false：不开启安全认证。 servicecomb_credentials_account_name 结合用户实际值配置。 servicecomb_credentials_account_password 结合用户实际值配置。 说明： 用户密码password默认为明文存储，无法保证安全。建议您对密码进行加密存储，请参考配置安全认证参数。

Spring Cloud微服务组件配置安全认证账号名和密码 配置文件配置方式 为微服务的“bootstrap.yml”文件增加以下配置，若已配置请忽略。 spring: cloud: servicecomb: credentials: account: name: test #结合用户实际值配置 password: mima #结合用户实际值配置 cipher: default 用户密码password默认为明文存储，无法保证安全。建议您对密码进行加密存储，请参考自定义实现password的加密存储算法。 环境变量注入方式 为微服务添加如表1所示环境变量。 添加环境变量，请参考管理应用环境变量。 表1 环境变量 环境变量 说明 spring_cloud_servicecomb_credentials_account_name 结合用户实际值配置。 spring_cloud_servicecomb_credentials_account_password 结合用户实际值配置。 说明： 用户密码password默认为明文存储，无法保证安全。建议您对密码进行加密存储，请参考自定义实现password的加密存储算法。

操作步骤 登录微服务引擎控制台。 在左侧导航栏选择“应用网关 ”。 单击待查看的实例的名称，进入该实例的基本信息页面。 在“基础信息”区域的“标签”参数处，您可以根据实际需要，执行以下操作： 新增标签 新增标签会影响网关业务十秒左右，请在业务低峰期时增加。 单击“标签管理”，弹出“编辑标签”窗口。 单击“ 新增标签”，您可在“标签键”和“标签值”中输入标签信息。 单击“确定”，为实例添加标签成功。 修改标签 修改标签会影响网关业务十秒左右，请在业务低峰期时修改。 单击“标签管理”，弹出“编辑标签”窗口。 您可在原有的“标签键”和“标签值”输入框中修改标签键与标签值信息。 单击“确定”，标签修改成功。 删除标签 单击标签所在行的，删除该标签。

重置密码 登录微服务引擎控制台。 在左侧导航栏选择“ServiceComb引擎专享版”。 单击待操作的开启了安全认证的ServiceComb引擎。 单击“系统管理”。 在弹出的“安全认证”对话框输入该ServiceComb引擎下关联了admin角色权限的账号名及其密码，单击“确定”。 首次连接ServiceComb引擎，请输入root账号名及创建ServiceComb引擎时输入的密码。 创建账号请参考新增账号。 在“账号管理”页签，选择待重置密码的账号名，单击“操作”列的“重置密码”。 输入“新密码”和“确认密码”。 查看提示信息确认需要重置密码后，勾选“我已确认知晓”。 单击“保存”，完成密码重置。