随着云计算的普及，越来越多的传统企业客户也在选择把IDC的业务系统搬到公共云上，实现更大的弹性、更强的灵活性、更高的性价比。但与泛互联网型企业的轻资产相比，传统企业的云下IT规模较大，有比较沉重历史包袱重，以及各种行业安全规范的约束，所以对于网络的规划设计、部署使用、运维管理都有自己的要求，仅仅具备云产品的初级使用能力已不能满足实际使用需求。企业级云上网络架构的重点是帮助企业用户更高效地搭建安全可靠的云上网络架构，本文主要针对企业客户在云上的南北向流量（访问internet/被internet用户访问）和东西向流量（企业内部VPC互访）的互访、安全、管理等多方面需求，利用CEN-TR（云企业网企业版）实现云上东西向+南北向流量安全和统一公网出口的最佳实践。
承接上一篇，这次跟大家分享一些与SQL优化相关的经验，希望能够帮助大家了解如果更有效率的使用ADBPG数据库。ADBPG数据库使用基于成本（cost-based）的优化器，像其他的数据库一样，在生成计划时会考虑联接表行数、索引、相关字段基数等因素，除此之外，优化器还会考虑数据所在的segment节点...
MSE 云原生网关默认提供了丰富的 Metrics 指标大盘，配合阿里云 Prometheus 监控提供开箱即用的完整可观测性能力，能够帮助用户快捷、高效的搭建自身的微服务网关与对应的可观测体系。
本次方案主要是针对阿里云国际站客户，企业在实际使用阿里云的过程中如何做好运维检测的一些多产品结合的方案介绍。 本篇文章的重点会放在检测（Detection）部分，会具体介绍涉及使用产品配置，FAQ等等，同时对整体的理论框架进行简单的介绍，帮助大家更好理解本部分在运维工作中的分属情况，更好的建立整体性的概念。
基于CEN-TR可以实现灵活地组网方案，在面向不同客户业务场景可以选择不同的组网策略。本文介绍了从最简单的VPC互联到各种复杂的组网方案，适用于不同规模企业在网络组网这块的需求。
ADB PG是一个经典MPP数据库，长项在于查询分析处理，面对客户联机分析和联机交易（HTAP）场景就显得力不从心，我们在某银行核心系统DB2 for LUW迁移到ADB PG时就遇到类似问题，因此我们提出ADB PG+RDS PG混搭技术架构，来解决客户此类HTAP需求。该混搭架构的精髓在于扬长避短，充分发挥分析型数据库和交易型数据库的长处和特性，分析型数据库专注于数据加工跑批场景，然后批量加工的结果数据卸载到RDS PG，通过RDS PG对外提供高并发对客交易服务。
用户画像在市场营销的应用重建中非常常见，已经不是什么新鲜的东西，比较流行的解决方案是给用户贴标签，根据标签的组合，圈出需要的用户。通常画像系统会用到宽表，以及分布式的系统。宽表的作用是存储标签，例如每列代表一个标签。但实际上这种设计不一定是最优或唯一的设计，本文将以PostgreSQL数据库为基础，给大家讲解一下更加另类的设计思路，并且看看效率如何。
