PTS压测体验之博客文章列表
PTS压测体验之博客文章列表一、简介性能测试PTS（Performance Testing Service）是一款性能测试工具。支持按需发起压测任务，可提供百万并发、千万TPS流量发起能力，100%兼容JMeter。提供的场景编排、API调试、流量定制、流量录制等功能，可快速创建业务压测脚本，精准模拟不同量级用户访问业务系统，帮助业务快速提升系统性能和稳定性。二、测试需求场景前段时间买了阿里云的轻量服务器搭建了一个博客，没事记录点东西，并且配置了cdn加速，自我体验还行，如果来博客来个压力测试，它能扛得住吗？有幸参加阿里云性能测试PTS 就那它试试吧！三、资源包领取这里领取了新人 0.99的一月体验包 领取后 进入控制台概览 会看到PTS 通用资源 10000 VUM四、创建测试场景这里选择了PTS 压测这里我配置了我博客列表页的接口api配置了最大并发100 压测时长1分钟（没敢配置太大，怕网站受不了） 预计会消耗500 VUM通过资源点确定 执行五、分析压测结果压测结束后即可看到压测的结果日志从图表上看来 成功率 100% 平均RT 2428ms TPS平均值4 峰值10 没有异常请求 总体请求241总体算是可以了 毕竟并发不高 对于一个小博客网站足够了 平常没有太大流量并发六、总结总体体验下来，感觉PTS性能测试，上手非常简单，作为一个前端开发也能轻松上手进行场景搭建以及测试，另外PTS的资源包价格相较于其他的压测平台还是很有优势的，大大降低了企业压力测试的成本。最后PTS支持的协议相较于其他平台优势更大，增加了支持 HTTP 2 协议，流媒体 RTMP/HLS 协议， Websocket 协议等，进一步扩大了压测协议支持的范围以及适用场景，解决了不同的技术架构无法压测的痛点！
程序分区模型（代码实例解析）
分区模型栈区由系统进行内存的管理。主要存放函数的参数以及局部变量。在函数完成执行，系统自行释放栈区内存，不需要用户管理。代码示例：char* func(){
char p[] = "hello world!"; //在栈区存储 乱码
printf("%s\n", p);
return p;
}
void test(){
char* p = NULL;
p = func();
printf("%s\n",p);
}
结果第一次可以输出，第二次输出乱码堆区由编程人员手动申请，手动释放，若不手动释放，程序结束后由系统回收，生命周期是整个程序运行期间。使用malloc或者new进行堆的申请。代码示例：#include<stdio.h>
#include<string.h>
#include<stdlib.h>
#include<iostream>
using namespace std;
char* func() {
char* str = (char*)malloc(100);
strcpy(str, "hello world!");
printf("%s\n", str);
return str;
}
void test01() {
char* p = NULL;
p = func();
printf("%s\n", p);
}
void allocateSpace(char* p) {
p = (char*)malloc(100);
strcpy(p, "hello world!");
printf("%s\n", p);
}
void test02() {
char* p = NULL;
allocateSpace(p);
printf("%s\n", p);
}
int main()
{
test01();
test02();
}
堆分配内存API：calloc#include <stdlib.h>
void *calloc(size_t nmemb, size_t size);
功能：在内存动态存储区中分配nmemb块长度为size字节的连续区域。calloc自动将分配的内存 置0。参数：nmemb：所需内存单元数量size：每个内存单元的大小（单位：字节）返回值：成功：分配空间的起始地址失败：NULLrealloc#include <stdlib.h>
void *realloc(void *ptr, size_t size);功能：重新分配用malloc或者calloc函数在堆中分配内存空间的大小。realloc不会自动清理增加的内存，需要手动清理，如果指定的地址后面有连续的空间，那么就会在已有地址基础上增加内存，如果指定的地址后面没有空间，那么realloc会重新分配新的连续内存，把旧内存的值拷贝到新内存，同时释放旧内存。参数：ptr：为之前用malloc或者calloc分配的内存地址，如果此参数等于NULL，那么和realloc与malloc功能一致size：为重新分配内存的大小, 单位：字节返回值：成功：新分配的堆内存地址失败：NULL示例代码：#include<stdio.h>
#include<stdlib.h>
#include<string.h>
void test01() {
int* p1 = (int *)calloc(10, sizeof(int));
if (p1 == NULL) {
return;
}
for (int i = 0; i < 10; i++) {
p1[i] = i + 1;
}
for (int i = 0; i < 10; i++) {
printf("%d ", p1[i]);
}
printf("\n");
free(p1);
}
void test02() {
int* p1 = (int *)calloc(10, sizeof(int));
if (p1 == NULL) {
return;
}
for (int i = 0; i < 10; i++) {
p1[i] = i + 1;
}
int* p2 = (int *)realloc(p1, 15 * sizeof(int));
if (p2 == NULL) {
return;
}
printf("P1=%d\n", p1);
printf("P2=%d\n", p2);
//打印
for (int i = 0; i < 15; i++) {
printf("%d ", p2[i]);
}
printf("\n");
//重新赋值
for (int i = 0; i < 15; i++) {
p2[i] = i + 1;
}
//再次打印
for (int i = 0; i < 15; i++) {
printf("%d ", p2[i]);
}
printf("\n");
free(p2);
}
int main()
{
test01();
test02();
return 0;
}
全局/静态区全局静态区内的变量在编译阶段已经分配好内存空间并初始化。这块内存在程序运行期间一直存在,它主要存储全局变量、静态变量和常量。例如：#include<stdio.h>
#include<stdlib.h>
#include<string.h>
int v1 = 10; //全局/静态区
const int v2 = 20; //常量，一旦初始化，不可修改
static int v3 = 20; //全局/静态区
char *p1; //全局/静态区，编译器默认初始化为NULL
void test() {
static int v4 = 20; //全局/静态区
}
int main()
{
test();
return 0;
}
注意：这里不区分初始化和未初始化的数据区，是因为静态存储区内的变量若不显示初始化，则编译器会自动以默认的方式进行初始化，即静态存储区内不存在未初始化的变量。全局静态存储区内的常量分为常变量和字符串常量，一经初始化，不可修改。静态存储内的常变量是全局变量，与局部常变量不同，区别在于局部常变量存放于栈，实际可间接通过指针或者引用进行修改，而全局常变量存放于静态常量区则不可以间接修改。字符串常量存储在全局/静态存储区的常量区。关于静态全局变量与非静态全局变量的讨论：关于静态全局变量与非静态全局变量的讨论，内容过多，大家可以看下面一篇文章：https://yangyongli.blog.csdn.net/article/details/120402589静态全局变量与非静态全局变量的使用说明1.若全局变量仅在单个C文件中访问，则可以将这个变量修改为静态全局变量，以降低模块间的耦合度；2.若全局变量仅由单个函数访问，则可以将这个变量改为该函数的静态局部变量，以降低模块间的耦合度；3.设计和使用访问动态全局变量、静态全局变量、静态局部变量的函数时，需要考虑重入问题，因为他们都放在静态数据存储区，全局可见；4.如果我们需要一个可重入的函数，那么，我们一定要避免函数中使用static变量(这样的函数被称为：带“内部存储器”功能的的函数)5.函数中必须要使用static变量情况:比如当某函数的返回值为指针类型时，则必须是static的局部变量的地址作为返回值，若为auto类型，则返回为错指针。代码示例：#include<stdio.h>
#include<stdlib.h>
#include<string.h>
char* func() {
static char arr[] = "hello world!"; //在静态区存储 可读可写
arr[2] = 'c';
const char* p = "hello world!"; //全局/静态区-字符串常量区
//p[2] = 'c'; //只读，不可修改
printf("%d\n", arr);
printf("%d\n", p);
printf("%s\n", arr);
return arr;
}
void test() {
char* p = func();
printf("%s\n", p);
}
int main()
{
test();
return 0;
}
总结数据区包括：堆，栈，全局/静态存储区。全局/静态存储区包括：常量区，全局区、静态区。常量区包括：字符串常量区、常变量区。代码区：存放程序编译后的二进制代码，不可寻址区。可以说，C/C++内存分区其实只有两个，即代码区和数据区。
如何保障移动终端安全？一文详解源自支付宝的全链路安全防护建设
近日，由中国电子银行网、数字金融联合宣传年主办的第五届（2022）数字金融创新大赛榜单发布，蚂蚁数字mPaaS全链路终端安全方案，获得“数字平台创新奖”。蚂蚁数字mPaaS是融合支付宝诸多科技能力的移动开发平台，为移动应用开发、测试、运营及运维提供云到端的一站式解决方案，其中在移动安全方面，mPaaS基于支付宝多年业务实践经验，形成了mPaaS全链路终端安全方案，帮助企业在业务移动化过程中解决网络安全合规等问题。6月24日，蚂蚁集团和互联网安全新媒体FreeBuf联合开展移动安全公开课，蚂蚁集团数字科技mPaaS技术专家叶鸣宇（夜禹）在线讲解了mPaaS移动安全合规整体解决方案与实践，我们将内容整理出来与大家分享。｜内容回顾｜夜禹从三个维度展开论述：首先，讲述移动APP当前的安全现状，包括移动安全、移动隐私合规的现状；其次，谈论蚂蚁如何解决终端安全上的问题，全链路安全合规体系如何加强安全防护能力；最后，就移动隐私合规管控体系在蚂蚁的应用场景做了简单介绍。｜移动安全合规现状｜根据信通院的数据显示，70.22%的金融行业App存在高危漏洞，6.16%的金融APP受到恶意程序感染，超80%的金融App未进行任何的安全加固，N款金融App存在不同程度的超范围索取用户权限的情况，以及某些第三方SDK存在隐蔽收集用户信息、自身安全漏洞等安全风险。由此可见，企业在业务移动化过程中APP的安全隐患问题普遍存在。再来看到隐私合规行业标准、监管活动以及处罚情况示例图，尤其在2021年11月1日起施行的《中华人民共和国个人信息保护法》后，企业对于权限隐私的保护越来越关注。截至 2022.3，工信部已组织检测21批次共244万款APP，累计通报2049款违规APP，下架540款拒不整改的APP，并且监管处罚还在继续。此外，自2015年起，国内金融机构开始尝试使用将人脸识别作为一种用户身份核验方式，并将APP的业务直接依赖人脸身份核验的结果。当人脸核验通过后，就具备了在线上开户、支付/转账、业务申办等权限，以致于黑产对人脸识别的攻击也越来越多，活体人脸核验技术安全亟待开发解决。｜全链路移动安全防护｜蚂蚁如何解决在终端安全上的问题？蚂蚁采用何种解决方案/架构体系提升安全防护能力？蚂蚁通过构建mPaaS全链路安全合规体系，体系覆盖安卓、iOS、H5、小程序等各个平台，也覆盖整个研发生命周期包括从开发到上线以及后期运维维护。整体体系图自下而上分为四类能力：1.???? 数据安全服务；借助“移动网关”、“威胁感知/设备风险”、 “安全键盘”、“安全计算/存储”等 ，保障移动 App 密码秘钥管理、数据传输、存储安全性、攻击动态防御，并借助“安全加固”，提供完善的 App 加固服务，保障应用线上运行避免篡改、破解、调试等风险。2.???? 安全隐私管控服务；借助“移动安全检测”、“移动隐私合规检测” 、“移动隐私合规切面”等，帮助移动 App 全面排查安全漏洞，评估个人信息采集是否合规，并提供安全问题修复方案及建议。3.???? 生物认证安全服务；借助“实人认证/活体识别”、 “证件识别”、 “人脸安全”、“IFAA 金融级身份认证”，实现金融 App 特定场景下身份认证安全，充分保障用户信息、业务交易数据安全性，同时对认证本身进行保护。4.???? 应用安全加固服务；借助“android安全加固”“ios/h5安全加固”，降低移动App在端上被破解、调试、篡改等风险。然而，“安全加固”不是万能的。对高手而言，移动App做加固加壳也会被脱壳，并通过其他手机上的App来注入代码越过业务上的逻辑限制。这种情况下，业务侧如何知道是否被攻击？或是“请求”是不是被黑产改造过的流量？又如何做到防护？支付宝以及蚂蚁各大App都引入移动网关，移动网关是连接移动 App 客户端和服务端的桥梁，也就是说，当流量打过来会经过网关再到后端进行验签和解密，流量到后端之后会被分发到业务侧进一步处理。终端安全SDK在端上对风险提前进行感知，并把端上的各种数据特征传输到后端进行大数据计算以及机器学习，同时会有专门的安全团队对数据做进一步分析。这形成一整套的黑设备感知、终端环境安全感知的能力，而这套能力/模型可以对网关打过来的各种业务流量进行监控，对恶意流量进行阻断或者引入陷阱等方式策略管控。这套解决方案不仅在支付宝内部可以使用，在外部App上也可以使用。典型应用场景发生在各类营销活动中，比如在抢各类券的活动中，通过这套解决方案可以把住黑产引入的“薅羊毛”流量。其他应用场景也有火车票抢票业务防刷、转账风控系统风险决策等。｜移动隐私合规管控｜支付宝根据多年实践沉淀出一整套的体系化解决方案，分为事前、事中、事后三层管控。? 事前主要是通过动静态风险扫描和权限合规授权2个方式来把控风险卡口审核。? 事中主要是通过移动隐私合规安全切面的方式来对所有的API进行一个切面，从而监控每个用户在使用过程中所涉及到的权限情况以及隐私异常的问题。? 事后就是出现问题后，企业方根据监控的数据下发指令对隐私异常或者有风险的地方进行阻断，从而把风险降到最低。目前，外部的很多厂商提供相关能力仅仅体现在事前的部分是无法完全把控风险的，而移动隐私合规解决方案可以帮助企业在测试过程中、在线上过程中以及出现问题之后快速响应及时管控。整体而言，移动隐私合规切面是核心点，一般“用户信息”是可以直接打到最下层的底层API调用的，但现在它被拦截并把所有的调用全部走到管控面，也就是从“1”到“2”的路径，通过这样的路径可以掌控线上整体情况，遇到问题时就可以进行回溯以及管控从而释放风险。怎样实操发现上述风险问题？蚂蚁做了移动隐私合规管控大盘覆盖一系列的隐私异常定义信息，包括超范围申请权限、超频次、后台调用等等。 当风险发生，可以根据调用链自动化生成管控下发配置进行关闭并且只定向关闭掉管控的那部分而不影响其他业务。｜交流与互动｜以上就是我们今天分享的全部内容！如有意向进一步沟通，欢迎大家扫码加入“蚂蚁mPaaS & FreeBuf公开课答疑群”钉钉群组，感谢大家参加今天的技术分享，希望有所收获。
巧用API网关构建大型应用体系架构
近期阿里云重磅发布了BizWorks一体化的云原生应用的开发和运营平台，内置阿里巴巴业务中台构建的最佳技术实践。BizWorks提供的产品能力，普遍适用于企业云原生应用高效开发以及企业业务能力沉淀和复用的场景。BizWorks提供业务架构师一整套的可视化业务建模工具，极大提升设计效率；同时，基于这套建模产出，形成代码框架，让业务中台复杂的变成过程简化为填空题，减低开发难度、提升研发效率，并在部署环节完成设计与实现的一致性校验，保证实现质量。BizWorks已经将API网关作为关键组件融入其中，并且基于API网关为用户提供能力开放平台。那么API网关是如何在BizWorks中起到作用？API网关在实际业务中又起到怎样帮助？本文就此展开详细说明。阿里云API网关是阿里云自研的一款高性能网关，主要面向公有云用户提供API托管服务、流控、认证、安全等能标准的API网关能力。阿里云的API网关原生对接了阿里云的非常多的标准云产品，能够将阿里云的多款产品聚合起来为用户提供一套整体解决方案，提供业务数据完全打通的能力强大的整套基础设施。本文详细描述了以API网关作为中枢的应用体系架构，用户可以参考本文快捷地搭建一套服务于大型应用的功能全面的服务器侧架构。1、应用体系架构的主要诉求我们运营一个成熟的APP，对服务器端大致有五种类型的主要诉求：处理业务类请求：处理用户自己业务系统的业务，比如客户端向服务器端发送的用户注册、登录、获取用户资料等请求，Web客户端向服务器端发送获取商品描述等请求；处理文件类请求：这个比较好理解，就是客户端向服务器端发送上传、下载文件的请求，比如图片，语音等多媒体文件；处理数据统计类请求：运营平台需要统计一些运营数据，业务大屏需要展示一些统计数据等，需要服务器端将业务数据经过聚合等处理后通过接口形式提供给Web客户端；调用三方接口处理特定请求：比如调用三方的人脸识别接口，三方的天气查询接口等专业接口；业务可监控，遇到异常情况可以自动报警对业务运行情况的监控和报警是一个服务器端架构必须要考虑的方面，这五类主要诉求都能通过API网关原生集成阿里云的其他标准产品来统一完成，下面我们来讲讲具体如何实现。2、API网关作为中枢的应用体系架构2.1、整体架构上图是利用API网关构建一个标准的APP服务器端架构图，我们可以看到API网关处于业务流量入口，原生集成了多款阿里云的标准产品。所有客户端的请求先发送到API网关，由API网关根据用户配置的API元数据将请求路由到不同的类型的后端实现不同类型的业务分发，API网关和这些后端类型产品是原生集成，默认内网通信，大幅降低用户配置难度的同时也提高了通讯效率。同时经过API网关的API调用日志都会被API网关实时同步到用户的SLS日志、云监控和ARMS业务监控中，大幅增强用户的业务监控与报警能力。2.2、统一的域名接入与业务分发API网关提供实用的域名与证书托管能力，用户可以将自有的域名和对应的证书托管到API网关上，所有的API均可以通过统一的自有域名对外提供基于HTTPS的服务，包括业务类请求，文件类请求和数据类型请求，由API网关将不同类型的API请求分发到不同的后端服务中去。API网关的域名与证书托管在业务接入方面为用户提供了一系列增强能力：API网关提供基于标准的跨域插件配置能力，用户可以在自有域名上为不同API配置不同的跨域策略，便于将自己的API提供给第三方或者自有的其他域名在浏览器上进行调用；API网关除了可以托管用户的单域名，还支持托管泛域名及其对应的SSL证书，适配利用泛域名提供业务的平台型业务，比如阿里的个人网盘业务就是使用的API网关进行的接入，API网关可以将泛域名的自定义部分作为参数传递给后端服务；API网关支持HTTP2的接入，可以大幅提高和客户端之间的通讯效率；API网关基于用户的不通需求提供三套不通的SSL接入算法选项，用户可以根据自己的业务安全级别来选择不通的安全策略；API网关同时支持HTTPS双向认证（Mutual TLS authentication)，在API网关验证客户端发送的SSL证书是否由用户的根证书颁发的。3、融合多款标准产品提供整套基础设施API网关除了可以对接用户自己的后端服务，还可以原生对接多款标准云产品，包括函数计算，OSS，及一系列数据类型的产品，用户可以轻易在控制台进行后端服务进行配置后就能完成对接，提供多款产品融合的强大综合服务能力。API网关与这些后端产品默认使用高效的内网通信。3.1、函数计算集成使用API网关与函数计算提供服务是业内标准的Serverless实现，可以充分利用API网关强大的接入能力和函数计算的代码托管能力和弹性收缩能力搭建大规模业务的Serverless服务器侧架构。Serverless架构大幅降低了用户的运维成本，将更多精力聚焦到业务逻辑的开发整合上，大大缩短开发周期。2019 年 双11 过后，世纪联华快速上云，将线上核心业务改造为全 Serverless 架构的中台模式，采用“函数计算+API 网关+OTS”作为计算网络存储核心，弹性支撑日常和大促峰谷所需资源，轻松支撑 618 / 双11 / 双12 大促。用户可以在API网关上直接配置已经在函数计算中定义的函数，直接选择对应的服务和其中的函数即可，配置非常简便：3.2、OSS集成去年API网关原生集成了OSS产品，用户可以使用API网关对其客户端提供文件管理API。OSS产品本身就对用户提供了文件管理API，为什么还要通过API网关去暴露用户的文件管理API呢，主要有以下几条原因：用户可以在API网关为每个文件、文件夹设置跨域策略，在Web类场景非常实用；用户可以通过API网关为每个文件、文件夹设置访问控制策略，可以规定某些文件只能通过鉴权后才能访问，API网关提供的鉴权方式比较丰富，除了AK签名方式，还提供了JWT方式和BasicAuth方式，能适应更多的实际使用场景；同时也可以为每个文件设置IP黑白名单策略；API网关提供了后端文件缓存功能，用户可以通过这个功能将热点文件缓存起来，大幅提升文件访问效率；统一的日志、监控、报警管理；用户可以在API网关上直接选择已经在OSS中创建的Bucket，API网关允许将整个Bucket配置成一个API，配置方式非常简便：3.3、数据类型产品集成用户通过自建的应用或者在函数计算上托管的服务对客户端提供业务类请求API，业务数据存储在阿里云的云数据库内。API网关目前已经与Dataworks，Quick BI等大数据分析平台进行原生集成，同时也和数据管理服务DMS进行了集成。用户可以将自己的业务数据通过大数据分析平台得到分析后的数据，然后通过API网关将这些数据能力通过API的形式开放给自己的运营平台或者开放给第三方。Dataworks直接将API网关嵌入到自己的产品中，用户在DataWorks生成数据API默认通过API网关对外开放能力。用户可以在API网关控制台看到这些API，并对其进行精细化管理，比如绑定流控、访问控制等插件来适配不同的业务场景。3.3、云市场API类商品集成API网关与阿里云的云市场做了深度集成，云市场的API类商品都是通过API网关对其消费者提供服务。用户可以将自己的能力、数据通过云市场的API类商品形式上架到阿里云的云市场来获取收益，也可以在云市场上购买三方API类商品，将这些三方公司开发的特定的能力集成到自己的APP中去，比如非常实用的人脸识别API，身份证识别和认证API，天气类API，IP识别API等等，这些通用能力有专业的公司去开发，直接借力这些三方公司的专业能力可以节省自己的研发成本而获得专业的服务。API网关在为用户生成调用API的SDK的时候，将用户自己API和在云市场上购买的所有API聚合在一起后生成一个统一的SDK供用户下载使用。3.4、SLS日志同步与监控报警用户可以通过配置，将所有经过API网关的调用日志同步到用户自己的SLS日志服务中去，通过SLS日志服务您可以进行实时日志查询、下载、多维度统计分析等，您也可以将日志投递到OSS或者MaxCompute进行远期备份或深度分析。用户还可以使用这些日志作为日志审计的数据源，日志审计是法律刚性需求，是客户安全合规依赖的基础，是一些项目的必选项，可以轻松通过配置实现。用户除了可以在日志中看到调用的基本信息，包括域名、调用者身份、调用耗时，应答状态码等基本信息外，还可以配置记录整个请求和应答，便于排查问题。用户将API网关的调用日志同步到SLS后，就可以在SLS中配置监控报警项了，配置内容比较简单：3.5、集成云监控API会自动将调用日志同步给阿里云云监控产品，用户可以在云监控产品上直接配置报警规则，监控报警的指标包括：Http应答码，API响应时间，请求次数，流入流量，流出流量。如果需要对该API分组下的所有API应用相同的报警规则，进入API分组详情页，点击详情页右上角的开启云监控：云监控报警可设置多级报警，阈值处于不同区间时，对应Critical 、Warning、Info三个不同级别，不同级别通过不同渠道发送报警通知。3.6、全链路追踪平台用户可以配置将调用日志上传到阿里云链路追踪平台，分析全链路调用情况。链路追踪 Tracing Analysis 提供了完整的调用链路还原、调用请求量统计、链路拓扑、应用依赖分析等工具，可以帮助用户提高开发诊断效率。配置好之后，就可以在全链路追踪平台上看到整个调用链每个节点的耗时情况了：4、API网关自身核心能力API网关除了提供API元数据和API生命周期管理能力外，在API调用环节贡献了一些主流架构中不可缺少的能力，以下任何一项能力要想做好都非常麻烦。API网关在线上为数万公有云用户提供服务的同时，也将自己的基本功打磨到好用的程度。4.1、流控流控是标准网关的基本能力，保护后端服务避免遭受过载请求的情况。API网关使用标准的令牌桶算法为用户提供多维度流控能力，下面是API网关提供的流控能力细项：支持API级别流量控制支持秒、分钟、小时、天等时间维度流量控制支持基于APP/用户维度流量控制根据请求参数（UserId等）、系统参数（IP等）设置流控策略使用标准漏斗算法，可以选择被流控请求缓存模式或立即返回模式4.2、鉴权API网关为用户提供多种形式的鉴权能力：通过托管用户的Public JWK实现对请求进行JWT认证，并将JWT解密出来的claim作为参数传给后端；在API网关生成AK/SK并且与API建立授权关系，客户端使用AK/SK对请求进行签名后才能调用授权后的API支持BasicAuth认证方式4.3、缓存用户将后端返回的应答缓存在API网关服务层面，有效降低后端的负荷，增加平滑度：支持根据请求参数、Header等维度来生成、获取缓存允许客户端通过Cache-Control头来影响缓存策略遵守后端应答中的Cache-Control头的约定来处理缓存4.4、安全API网关为用户的API调用提供多项安全保障：支持API级别IP黑名单和白名单支持前后端支持签名验证来确保请求在链路上不被篡改具备防重放能力，拒绝重放请求根据请求参数或上下文，来执行条件判断，用于过滤不希望传递到后端的请求支持读取JWT解密出来的claim中的参数作为判断条件来过滤请求4.5、性能API网关连接数和RPS支持无限制扩容专享实例中，请求在API网关的平均耗时为1ms5、API网关融入BizWorks成为能力开放平台API网关嵌入到DataWorks中，同时承接了BizWorks南北向流量和东西向流量的治理工作。商业能力上架的时候，商业能力下的所有API的元数据会自动注册到API网关，由API网关向外部开放其能力。开发者登录到运营平台的开发者门户去浏览搜索所有商业能力，查看商业能力的API定义，下载商业能力下所有API对应的SDK。API的调用数据也会同步到SLS中，BizWorks的能力运营数据平台会去分析调用数据，将调用数据中的价值挖掘出来，供决策人员参考。6、总结API网关是阿里云的一款在线上平稳运行六年多的成熟云产品，为广大用户提供标准的高性能网关服务，它除了能提供API托管服务，覆盖设计、开发、测试、发布、售卖、运维监测、安全管控、下线等API各个生命周期阶段，还集成了阿里云的众多标准云产品，能够将众多云产品连接起来搭建成一个功能强大的、省心的服务器侧架构。API网关后端原生集成了OSS、函数计算、Dataworks等数据分析类产品，满足用户业务处理，文件处理，数据分析等基本诉求。API网关将调用日志同步给了SLS，云监控，全链路追踪平台，满足用户多维度业务监控报警的需求。API网关同时融入了阿里云最新发布的强大的云原生应用的开发和运营平台BizWorks，成为BizWorks的能力开发平台的核心组件。
阿里云云原生学习及思考笔记-云原生理解
真正的云化不仅仅是基础设施和平台的变化，应用也需要做出改变，摈弃传统的土方法，在架构设计、开发方式、部署维护等各个阶段和方面都基于云的特点，重新设计，从而建设全新的云化的应用，即云原生应用。云原生是指从云的原生应用角度出发，一整套设计、开发、部署、运行、维护的流程、技术栈以及背后文化理念的统称。[1]从这个角度来看，与云原生对应的是传统的部署方式。用来对比的是云原生应用和传统应用。云原生的发展脉络[1]在接下来的《云原生时代》系列报告中，我们将依照这些概念，分成DevOps与CI/CD；微服务、API管理与集成；容器与Docker；Kubernetes与容器编排之战四个部分全面介绍云原生各个组成部分。[2]2.API，容器，微服务之间的关系又是如何？API 是应用程序编程接口（Application Programming Interface）的缩写。维基百科指出，“总的来说，它是各种组件之间的一组明确定义的通信方法”。现如今，当人们谈论 API 时，他们通常指的是通过 HTTP 端点公开的远程接口。为了区分这些远程 API 和上面提到的本地系统 API，我将用术语“Web API”指代远程 API。我们通过底层设计范式（如查询、RPC 或 RESTful）或协议（如 SOAP、gRPC 或 GraphQL）进一步对远程 API（或 Web API）进行分类。除此之外，我们还通过目标受众来区分 API，将它们分为公共、合作伙伴或私有 / 内部 API。微服务，又叫微服务架构，是一种软件架构方式。它将应用构建成一系列按业务领域划分模块的、小的自治服务。在微服务架构中，每个服务都是自我包含的，并且实现了单一的业务功能。简单来说，就是将一个系统按业务划分成多个子系统，每个子系统都是完整的，可独立运行的，子系统间的交互可通过HTTP协议进行通信（也可以采用消息队列来通信，如RoocketMQ，Kafaka等）。[3]如果没有容器，要么把服务器配置成可以运行多个微服务，让这些微服务不可避免地相互产生负面干扰，要么每个微服务都需要一个单独的服务器或自己的虚拟机，导致不必要的开销。因此，微服务通常被部署在一组由容器集群软件（如 Kubernetes）管理的一组容器中。可以肯定地说，容器和微服务的崛起其实是相互影响、相互促进的结果。基于微服务架构构建的应用程序或 API 不仅要把自己完全暴露出来，还需要在内部组件（微服务）之间建立连接。由于每个微服务都可以使用不同的编程语言实现，我们需要依赖标准协议（如 HTTP）来建立微服务之间的连接。这个时候我们就回到了 API 上。[2]3.DevOps与CI/CD呢？DevOps才得到了快速的发展。DevOps不单是一个实现自动化的工具链，而是组织、流程与技术的结合。组织上强调全栈团队、团队特性专一、团队自治；技术上打通开发与运维；流程上强调端到端、可视化、灰度升级、A/B测试等。对于DevOps，微服务不是必须的，但微服务为DevOps提供了最好的架构支撑，对于组织和流程的要求也是一致的。所以，也有人称微服务是DevOps架构。持续集成（CONTINUOUS INTEGRATION，CI）指的是开发人员频繁的（一天多次的）将所有开发者的工作合并到主干上。这些新提交在最终合并到主线之前，都需要通过编译和自动化测试流进行验证，以保障所有的提交在合并主干之后的质量问题，对可能出现的一些问题进行预警。持续集成的核心在于确保新增的代码能够与原先代码正确的集成。与持续集成相比，持续交付（CONTINUOUS DELIVERY，CD）的侧重点在于交付，其核心对象不在于代码，而在于可交付的产物。由于持续集成仅仅针对于新旧代码的集成过程执行了一定的测试，其变动到持续交付后还需要一些额外的流程。与持续集成相比较，持续交付添加了测试Test->模拟Staging->生产Production的流程，也就是为新增的代码添加了一个保证：确保新增的代码在生产环境中是可用的。持续部署（CONTINUOUS DEPLOYMENT）指的是通过自动化部署的手段将软件功能频繁的进行交付。与持续交付以及持续集成相比，持续部署强调了通过自动部署的手段，对新的软件功能进行集成。同持续交付相比持续集成的区别体现在对生产的自动化。从开发人员提交代码到编译、测试、部署的全流程不需要人工的干预，完全通过自动化的方式执行。这一策略加快了代码提交到功能上线的速度，保证新的功能能够第一时间部署到生产环境并被使用。DevOps、持续集成、持续交付、持续部署并不是某种技术栈或者框架，而是开发文化、流程、理念和操作方式。[4][1]https://zhuanlan.zhihu.com/p/143417185[2]cloud.tencent.com/developer/news/378771[3]https://zhuanlan.zhihu.com/p/66190538[4]https://zhuanlan.zhihu.com/p/143424111
安卓手机在定位能力方面提供了哪些API？
安卓手机在定位能力方面提供了哪些API？
Neuron Newsletter 2022-06｜新增 1 个南向驱动、开源前端代码
六月，我们发布了 Neuron 2.1.0 版本，这个版本主要与 eKuiper 进行了深度集成，可一键部署携带数据处理功能的 Neuron。此外，我们主要专注于新驱动的开发，新增南向驱动 DLT645，并对部分功能进行了优化，以更加贴合实际应用场景的使用。Neuron 的 Dashboard 页面进行了开源，用户现在可以对前端界面进行定制化的开发。DLT645 驱动DLT645 驱动适用于 DL/T 645-2007 通信协议，插件支持根据不同的数据标识，自动选择对应的数据格式。目前插件支持 UINT8/UINT64/DOUBLE 数据类型，支持读取 DI3 = 00 , 02 的全部数据标识和 DI3 = 04 的部分数据标识。插件还支持两种连接方式：串口连接和 TCP 连接。新增功能概览新增 IEC104 协议支持设备主动上报数据处理的功能，提高了 IEC104 采集数据点位的效率。新增 Dashboard 数据处理引擎的集成，现在可以直接通过 Neuron 的配置页面，配置北向 eKuiper 插件后（安装包已默认配置），可在数据处理选项中配置数据处理规则，详细使用方式可参考官网文档。新增定制化的 Modbus TCP 模拟器，模拟器支持以标准的 Modbus TCP 协议进行读写数据，并且支持扩展的 Modbus TCP 协议，可以一次读取 65535 字节的数据。重构 Neuron 核心代码的实现，现在 Manager 以及各个 APP 以及 Driver 对应的 Adapter 采用 Actor 模型实现，所以操作都会转换成相应的消息类型，且投递消息到 Manager 或者是 Adapter 对应的消息处理队列，进行顺序处理，解决了很多并发导致的问题；并且现在 Neuron 核心中各个模块采用了无锁的实现，提高了稳定性和对接设备性能。重构了 HTTP API 的参数，使用 PLUGIN/NODE/GROUP/TAG 相应的名字替换 API 中使用的 ID 字段，增强了 HTTP API 的易用性，调用 API 无需再调用其他 API 获取对应的 ID 了。问题修复根据社区反馈较多的一些编译问题，Neuron 删除了一些不必要的依赖库以及删除合并了一些重复的导出头文件，统一 Neuron 中使用的 HASH TABLE、LIST、ARRAY 等数据结构，降低了参与 Neuron 项目开发的门槛；删除了无法在较低内核版本的 Linux 中使用的特性，以使 Neuron 可以在更低端的设备中使用。修复了在之前版本中发现的内存泄漏问题。修复了在之前版本中发现的核心数据异常以及某些驱动对接设备异常的问题。其他更新完善了 Neuron 2.1.0 的官网文档，增加了一些设备配置范例以及一些对应 Neuron 版本的修改。
New Relic 可观测平台调研
前言New Relic 是美国的一家软件服务供应商公司，2008年 38岁的 Lew Cirne创建了该公司。该公司提供了一套集成的可观测性平台，平台允许用户对部署在云中心或在数据中心的 NET, Java, JavaScript, Node.js, PHP, Python, and Ruby 、基础设施、端等进行运维监控。 通过该平台开发人员和运营团队监控用来故障排除和优化他们的应用程序。 Lew CirneNewRelic 发展几个重要里程碑：2008年 Lew Cirne 创立NewRlic公司2010年 APM产品被CA Technologies 以3.75亿美金收购2014年 12月12日 以NEWR作为股票代号在纽交所上市2015年 宣布拥有 1万家客户，其中包括Runkeeper，Tableau， Nike，Gawker Media， ESPN，Sony，Comcast，E*Trade，eHarmony，GitHub，Groupon，Zumba 等 营收超2016年 Gartner 评为APM市场的领导者2020年 营收达到6.36亿美元目前公司2000多人随着可观测赛道的玩家越来越多，更多的如DataDog Dynatrace 的竞争，NewRelic的营收增长目前也面临着很大的压力平台能力概览New Relic One 是newRelic 的一个全栈监控的平台。他可以将你所有的场景资产监控数据聚集到一个平台来进行分析洞察。全栈监控应用程序监控基础设施监控k8s 监控日志管理网络监控浏览器监控移动端监控链路监控serverless 监控机器学习模型性能监控可观测性体验IDE集成调试、工作流错误跟踪数据探索AIOps数据采集和洞察数据接入仪表盘告警OpenTelemetry部分功能介绍本文将主要围绕 NewRelic的 浏览器监控、告警功能、自定义App进行详细描述。1. Browser Monitor浏览器监控是大部分可观测性产品必备的功能之一。通过接入浏览器监控探针，用户可以对产品浏览器端的数据进行监控。监控包含页面响应性能指标、页面js异常数据、页面请求数据、静态资源加载数据、客户端信息、geo信息等进行采集和监控。通过这些数据，用户可以对自己关切的业务界面进行即使的故障处理以及界面优化。1.1 接入方式newRelic 提供了两种浏览器监控的接入方式探针模式探针模式是使用最多的一种接入场景。随着SPA应用的普及，只要在单一入口页面埋入探针（上图中的探针js代码），即可完成探针的接入。APM模式服务端安装脚本，自动分发探针到html页面。比较适合多页面的场景。第一种探针模式需要手动为每个页面添加，比较麻烦。apm模式只需要在web服务层的代码上加入apm client，即可完成自动分发。当然也有一些限制。比如静态页面走cdn场景或者web服务层语言框架本身不支持的一些场景。以go 语言的一个web服务为例。只需要在服务侧对http路由进行newrelic的包裹函数即可完成配置和传统的浏览器监控应用一样，newRelic 也提供了常规的一些功能1.2 报表统计 1.3 自定义api提供自定义上报用户信息，如uid标示，其他业务关联信息等 如API：setCustomAttribute提供了各种钩子函数，提供不同的时间机制进行数据的上报或者其他控制1.4 数据聚合 对路径相同，参数不同的数据进行聚合。提供了模式匹配1.5 度量规范配置 对同类的异常指标进行更好的分组。避免分组多散导致基数过高，服务性能会受到影响 1.6 上报范围管控newRelic提供了三种模式。 Lite模式，只上报页面加载的一些性能数据 Pro模式，上报所有的页面信息 Pro+SPA模式，上面所有页面信息以及单页应用路由的一些信息和一些span的链路追踪1.7 黑白名单配置等 提供了host的黑白名单配置，所在国家地区的黑白名单配置1.8 trace通过在头部设置sessionID 和 span的一内容来关联上下游链路2. Alerts&&AI 数据洞察是数据采集后的重要一环。也是数据真正价值的体现之一。而告警正是数据洞察的一个重要形式之一。在newRelic的告警体系里。包含：事件系统、决策系统、通知系统、开放告警、工作流、AI等2.1 整体架构： 2.2 工作步骤：NewRelic 提供了自定义告警 Policy 和 预制内置告警（pre-built） Policy。以及异常巡检（Anomaly detection） Policy。 系统按照 Policy设置的定时活着其他策略去扫描数据，按照不同的条件。产生异常事件。异常事件也可以开放api对接其他告警系统的事件。异常事件进入事件系统后，会转交到决策系统Decisions。决策系统会自动合并同类事件。关联相关资源（比如其他的告警事件，巡检事件等）。NewRelic 还集成了一些内置的黄金指标的AI模型供用户进行打标。用户可以在incident里对此次资源关联进行打标，模型会自动优化。 newRelic提供了默认的决策逻辑，当然也提供了一些自定义的决策逻辑。供用户来按照一些属性对不同的事件关联。decision设置的越好，告警的降噪关联效果也会越好。 决策系统最终会将多个事件 按照决策规则聚合成Incident，以及将多个incident生成工作流中issues，供工作流中的值班人员全局查看评估。NewRelic告警里有一个全局配置的静默策略（Muting rule）。静默策略可以设置全局匹配的属性条件。当incident 符合静默策略的条件。将进行静默操作 如果一个incident不在静默策略范围中，将继续向上进入通知渠道。通知到Policy里设置的渠道，例如邮件、slack、pageDuty、webhook，同一个NR账号体系下的users等。newRelic 的issue是决策系统将 incident聚合后产生的一个问题。用户可以在界面上通过issue 查看所有incident以及incent的关联逻辑。还以通过工作流对issue进行定期的汇总和通知到工作流平台中。比如webhook 、jira，slack，等 Issue 面板包含了聚合的incident信息的展示，通知渠道的展示，source的展示，Root cause 的分析，以及issue time-line的信息 用户可以对告警Policy设置RunBook。RunBook 可以在告警触发的时候提供可执行回调进行自动化的问题处理逻辑。或者提供处理该类问题的文档链接，供运维人员进行查看，提高效率 3. 自定义APP在newRelic里提供了一个自定义app的UI定制功能。传统的运维产品模式下，用户只能依赖平台提供的可视化仪表盘来构建一些大盘视图。对于定制化要求高的客户来说，如何打通自己需求以及平台限制显得特别重要。往往大客户都有自建的统一风格的运维平台，可观测性产品对于大客户来说更多的是运维平台的一环。他们不希望通过多个不一样的界面来完成运维。newRelic里提供了一个cli工具，让用户可以像编写小程序一样，自定义自己的应用。平台提供了cli工具搭建应用框架，sdk调用平台开放数据。component 提供平台对外暴露的一些组件。用户通过这些组合自由定制自己场景需要的视图。自定义app提供了远程调试，发布，上传等功能。newRelic还提供了一个类似app中心的生态，你可以安装别人开放的app到你的应用下。3.1 自定义app的开发流程：1.Cli工具安装2.编写代码3.调试（在线/本地）4.发布app自定义APP基于react框架编写，客户需要做的就是完整render函数组件的定制开发 编写react 组件：通过nr提供的ui组件和数据组件进行开发：界面效果：更多的开发细节可以参考官方文档进行探索。最后正如第二章节提到，newRelic还有很多有意思的功能，后续会继续探索。newRelic 提供了一个免费的100G/月的版本使用。当然会有一些功能限制。因为newRelic的数据中心主要是在国外。国内使用部分功能会有异常，包括ui的加载延迟也会比较高。在阿里云日志服务产品中，目前也集成了 RUM功能模块，以及功能丰富的 告警功能 感兴趣可以使用。
三款“非主流”日志查询分析产品初探
前言近些年在开源领域，用于构建日志系统的软件有两类典型：Elasticsearch：基于 Lucene 构建倒排索引提供搜索功能，DocValue 存储支持了其统计分析能力。Clickhouse：列式存储是其优秀 OLAP 性能的保障。这里把上述系统归入 schema-on-write 系列。百花齐放，本文介绍三款 "schema-on-read" 类型日志系统。为什么是打了引号的 schema-on-read？尽管几家厂商对外宣传关键词常常用到 index-free、schema-less，但从技术角度应该理解为一种轻量级索引技术，将大部分计算成本后置到使用时发生。它们的出现有其背景：技术能力：硬件技术快速发展，云计算 IaaS 资源（计算、存储、网络）已足够便宜、弹性。客户诉求：近两年市场紧缩，企业的 IT 预算更加精细。场景固化：相当比例的日志使用场景具有写多读少、随时间变长热度降低特性。Humio简介Humio 是 2016 年成立的一家英国公司，2021 年 3 月被 CrowdStrike 收购（$352 million 现金加 $40 million 股票期权）。产品提供日志的搜索、统计、仪表盘、告警服务。数据路径Humio 用 Kafka 充当数据 buffer，落盘数据到内置存储供查询分析。可以开启投递到 S3。由于轻索引方案延迟表现不满足告警、仪表盘场景，但大部分时候它们的 query 模式固定，且按时间顺序进行。Humio 的方案是流计算，在数据摄入的 pipeline 中计算告警和图表：只处理实时数据。数据不需要排序。数据都在内存中更新。存储内置存储主要服务的是日志搜索、分析场景，数据的压缩、索引对于后续的计算性能有决定性影响。Humio 将数据按照 bucket 排列，在 bucket 上做好一些标签，标签内容包括：数据的时间区间。数据的来源、类型。基于数据 key-value 的 bloom filter（增加 4% 存储以支持随机关键词）。bucket 标签实际是一种粗粒度的索引，区别于以往对单条日志的细粒度索引。query engine 在计算时根据标签信息判断数据是否可能在 bucket 内，只读取相关的 bucket 数据。计算Humio 语法是管道式 SPL：#host=github #parser=json| repo.name=docker/*| groupBy(repo.name, function=count())| sort()对应的执行计划：读数据、标签过滤、扫描过滤、聚合计算、结果写出。暴力搜索通过分布式 mapper 可以加速，就单实例而言其加速策略如下图：ChaosSearch简介ChaosSearch 2016 年成立，2020 年 11 月 B 轮融资（估值 $40 million）。在 2021 年，员工增加一倍（50~99 之间），收入 YoY 611% 增长。ChaosSearch 提供多租户的 SaaS，面向日志和 BI 分析场景，主要是 Elasticsearch 兼容市场。索引对象存储上的数据，支持搜索、SQL、ML 计算。ChaosSearch 对于数据源的要求最为宽泛（放在对象存储即可），以 Data Lake Engine 来宣传。目前支持 AWS、GCP，计划今年加入 Azure 支持。数据路径使用过程如下：存入日志（通过 Logstash/Fluentd/Vector 等软件直接上传到 S3）。ChaosSearch 配置连接串，执行索引过程（支持周期性，实时两种模式）。通过 ChaosRefinery 创建数据视图。通过 API 或第三方可视化工具查询分析视图数据。对象存储上的日志有以下要求：支持三类数据：csv、log files（近 40 种流行格式）、json（BI 分析友好）。文件大小建议为 10MB gzip 或 50~500 MB 原文。超大文件不利于并发度提升且消耗更大索引内存；过小的文件则会导致查询性能降低（依赖 compaction），同时大量文件会导致索引问题（实时索引依赖消息通知，而 AWS SQS 等系统存在系统限制）。partition 机制有助于提升查询性能，可以在索引阶段将业务字段值设置为 partition 的一部分，建议一个object group 不超过一万 partition。索引阶段读取 S3 文件，异步建立索引，将索引数据存储到用户的 S3 上作为 metadata。存储ChaosSearch 支持自动 schema 探测（可枚举的格式）或主动字段抽取（正则），生成的索引数据称为 ChaosIndex。按照文档举例，其索引膨胀量在 5-10% 左右。Elasticsearch/Lucene 处理 1 PB 数据（压缩后）产生 5 PB 索引量，对应的 ChaosSearch 索引量在 250 TB 左右。其索引算法效果描述亮眼，但缺少进一步资料确认，引述文档内容如下：In the case of Chaos Index, it provides compression ratios upward or greater than Gzip, with the speed of Google’s Snappy compression algorithm. Up to 95% compression at high performance.Text-based queries are up to 10x faster to index and up to 2x faster to search when compared to Lucene.Analytic queries are up to 5x faster to index and up to 2x faster to query when compared to column stores.计算计算的一种场景是 ELT（Chaos Refinery），将原始数据做一些简单处理形成视图：最终的场景是为了搜索、分析，数据存储在 S3，对应的算力由同区域 EC2 提供。算力弹性、query plan 优化、索引优化是体验的三个重要因素。查询结果限制最多返回 500 条（这一点和 Loki 也一样，应该是性能上的保护考虑）。用户通过 Kibana 来完成查询页、分析图表、仪表盘和告警。提供三种 API 形态：ChaosSearch API、S3 Rest API、Elasticsearch 兼容 API。费用作为 SaaS 服务，其计费模式非常简单：按照写入流量计算，$0.8/GB（不限 query 数）。用户的另一部分费用是存储，直接交给云厂商，包括日志原文以及 ChaosSearch 生成的索引数据。这种计费模型有一定好处，一次性付费后，查询起来没有心理负担。厂商在超卖之后如何兑现算力是另一个话题：用户开启 burst 模式申请更多计算资源。Opstrace简介Opstrace 在日志查询、分析上的深入程度比起 Humio、ChaosSearch 有差距，单列出来实为突出 Grafana 生态。Opstrace 成立于 2019 年初，2021 年底被 GitLab 收购（是其上市以后的首次收购）。Opstrace 的关键词是开源（Datadog/Splunk/SignalFx 替代品），一套自动化编排流程帮助用户实现可观测平台。Opstrace 目前支持 AWS、GCP 部署，计划扩展至 Azure（好像 Azure 总是被排在后面，跟市占率不太匹配）。编排Opstrace 提供 SaaS 能力，有独立的数据写入、读取 API，无论是 log 或 metric 都存储到 S3。套件的主要部分是：监控：Prometheus API。日志：Loki API。采集：目前覆盖到开源（以 Prometheus、Fluentd、Promtail 作为客户端），未来计划扩展至 Datadog。当创建出 Opstrace 实例后，编排实现了云资源的准备（VPC、S3、EKS、ELB、Route53、EC2 等）、软件的部署（Prometheus、Loki 等）。底层组件（Loki 部分）Loki 是 Grafana 公司开源的一款日志分析软件，主要思想是用“Label Index + 暴力搜索”来解决问题。和 Elasticsearch 形成明显的差异：写多读多，强 Schema 日志模型能实现可预期的低计算延时。写多读少，非全文索引模式将成本大幅缩减并后置到查询时产生。Loki 的文档和代码资料都很多，这里只作简单介绍。数据存储：Index：Label 索引定义为 meta 字段索引，要求 cardinality 小（否则会索引爆炸，实测出现系统不可写入情况），例如在 K8s 场景 namespace、container、host、filepath 作为 Label 来搜索是非常合适的。Chunk：日志正文，行存格式，一组日志排列在一起，每条日志只包括 Timestamp 和 Line 两个字段。Index 存储：历史上写过 NoSQL，就目前情况来看未来都会用 S3（用 boltdb 来写索引文件，定时 flush）。Chunk 存储：一直建议用 S3 这样的对象存储。架构上多个角色分工明确，可以独立扩容：Distributor：接受数据写入，根据协调服务内容转发数据给 Ingester。Ingester：处理数据写入，负责 Chunk 构建，flush 数据到远端存储。响应赖在 Querier 的查询请求（内存未 flush 部分）。Query Frontend：查询请求处理的第一站，负责简单的 query 改写，大 query 切分与分派，cache 处理。Querier：查询请求的 mapper 节点，负责 query 解析、执行，数据拉取，结果合并。Ruler：调度器，用于预计算。L abel 索引方案在做大规模 metric 计算时可能延时较高，部分场景下可救急。Loki 的语法是 LogQL：查询：体验优秀，管道式，很顺畅。实测下来性能也不错（例如 600 byte 原文中搜索 32 byte 内容，单核处理 3GB/s），但有 5000 条结果上限（没找到翻页机制）。分析：语法从 Prometheus 继承而来，不好记，并且明显的时序结果导向在分析场景下显得片面了（SQL 已成为标准）。举一个例子：大括号里面的部分是 Label 匹配，其后的计算都是扫描部分。{container="query-frontend",namespace="loki-dev"} |= "metrics.go" | logfmt | duration > 10s and throughput_mb < 500Loki 存储格式是行存，统计分析很难做出高效率。查询的效率取决于 Label Index，因此其依赖一种 K-V 读写的存储，通过一套编码机制来细化数据读取范围。v11 编码机制如下：用途HashValueRangeValueValue查找有哪些日志线（用 label hash 区分）metricName -> seriesIdfmt.Sprintf("%02d:%s:%s", shard, bucket.hashKey, metricName)encodeRangeKey(seriesRangeKeyV1, seriesID, nil, nil)empty根据 label 名查找有哪些候选的取值（用于下拉提示）labelName -> hash(value):seriesIDfmt.Sprintf("%02d:%s:%s:%s", shard, bucket.hashKey, metricName, labelName)encodeRangeKey(labelSeriesRangeKeyV1, sha256bytes(labelValue), seriesID, nil)labelValue根据日志线，查找有哪些可用的 label 名（用于下拉提示）seriesId -> labelNamesseriesIDencodeRangeKey(labelNamesRangeKeyV1, nil, nil, nil)labelNames根据日志线，查找 chunk 存储位置（用于拉取命中的 chunk）seriesID -> chunkIDfmt.Sprintf("%s:%s", bucket.hashKey, seriesID)encodeRangeKey(chunkTimeRangeKeyV3, encodedThroughBytes, nil, []byte(chunkID))empty在不考虑严重数据时间乱序情况且 label cardinality（万以下）可控时，索引膨胀比在 千分之一到百分之一之间，S3 单价便宜，另外可以和 Grafana metric 生态形成体验的融合。这可能就是 Opstrace 选择 Loki 的原因。参考https://www.humio.com/blog/https://library.humio.com/stable/docs/index.htmlhttps://www.youtube.com/watch?v=NF-IDXelm4I&list=PLrhuCswD2Pa0hpPs3XhD_ORmvAiCjiyiX&index=7&t=13shttps://www.chaossearch.io/bloghttps://docs.chaossearch.io/docshttps://opstrace.com/blog/why-cortex-lokihttps://opstrace.com/docshttps://grafana.com/docs/loki/latest/绝大部分图片摘自几款产品的文档或博客。
