- 金融行业背景介绍
- 随着线上金融交易平台的成熟和增多，很多平台都遭受了黑客或者竞争对手的攻击，致使用户数据丢失或者无法提供服务，频繁的攻击给企业和用户造成很大损失。长此以往用户量急剧减少，最后导致用户丢失现象非常严重。现有的框架已经无法支撑平台的正常运营。加之现如今越来越多的平台重视用户体验和数据安全，这就需要一个完整的框架来支撑整个平台的正常运行。主要能解决面临的两大核心问题，即网络安全和数据安全。唯一网络在长期的运营和大量实践中为用户摸索出一套完整的方案。依托唯一网络自身的行业优势和优质资源解决了目前互联网金融行业存在的问题，为用户的业务保驾护航。
客户需求
- 跨机房备份，其他非同城机房。
- 机房出口宽带充足，能预防DDoS攻击。
- 至少两个不同地区机房之间有物理专线连接。
- 当有攻击或者网络故障时随时切换到其他机房节点。
- 对网络攻击较为敏感，具备网络安全防御系统。
解决方案
- ABC三个机房均采用双线路或者多线路。
- 采用A机房主用，B机房网络备用和C机房高防节点备用的方式。ABC机房都有防御系统，能抵抗CC和大流量攻击。
- 机房网络都是直连骨干网络，机房核心网络都采用高端路由器，并有多台备份。
- 防火墙采用多台模块化防火墙集群，高密度万兆端口提高防御能力。实现有针对性的防护策略和独立主机规则。
- A机房和B机房之间有专用链路并有备份线路，A机房服务器和B机房服务器实现内网直接备份,数据同步和切换。
- 全天候监控网络数据包，并根据自身规则判断是否攻击型数据包。
- 美柚：
- 唯一网络在IDC方面的支持，资源良好，服务积极，秉承着“急用户之所需，想用户之所想”的理念，对于我们提出的个性需求能迅速提供解决方案，大大提高了工作效率，和唯一网络的合作无疑是个正确的决定，希望能继续保持良好的合作共赢局面。
- 懒人听书：
- 感谢唯一网络为我们提供了优质、可靠、稳定的网络解决方案，在使用过程中，唯一网络提供快速、高效、完善的售后服务。同时能够针对我们不断变化的业务提供符合我们需求的解决方案，与唯一网络合作多年，我们非常满意。
- 迅雷：
- 与唯一网络合作已有两个年头，这个团队有优良的技术和高品质的服务，技术力量让我们非常满意，合作期间业务一直运行稳定，大大节省了管理成本、提高了工作效率，唯一网络是我们可信赖的合作伙伴。
- 中国平安：
- 我们十分看重唯一网络高品质的带宽资源，而其良好的服务意识让我们更坚定地选择了该公司作为合作伙伴，我们的互联网业务有唯一网络这样优质服务商的支持才能不断发展，相信未来的合作领域还会更加宽广。
- 创维：
- 唯一网络的技术实力和售后服务我们很认可，出现故障的时候细致分析，快速高效帮我们处理网络问题，企业发展得益于技术和服务，唯一网络已经达到较高的水平，是一家值得认可的IDC企业，是我们可信赖的合作伙伴。
- 39健康：
- 在尝试了多家号称高防的机房和产品后，发现唯有唯一网络是真正能防住流量攻击的，产品可靠，服务可信！
相关文章推荐
阿里云RDS分库分表扩容兑现平滑数据迁移 2020年，笔者负责的一个高德打车弹外订单系统进行了一次扩分库分表和数据库迁移。该订单系统全局部署在阿里云上，服务应用阿里云ECS部署，数据库采纳阿里云RDS，配置中心基于阿里云ACM自研，数据同步基于阿里云DTS自研以及自研分库分表组件、分布式ID组件等等。 此次进行扩分库分表的背景是，原4实例4库、各个库64张表一共256张表，部分单表已超千万量级，按目前每日单量量级，一年内单表会达到上亿条记载，单表数据量过大会带来数据库性能问题。 4实例（16C/64G/3TSSD），4库（各个实例一个库），每库64张表，共256张表。 经过RDS后台一键诊断功能，来计算表空间应用情形（这里拿测试情境数据库举例）。 数据库的瓶颈主要表现在：磁盘、CPU、内存、互联网、联结数，而联结数主要是受CPU和内存作用。CPU和内存可以经过动态升配来提高，可是SSD磁盘容量最大支持到6T（32C以下最大3T、32C及以上最大6T）。 可是现阶段兼顾成本，可先将实例扩容一倍，采纳8个实例(16C/64G/3TSSD)，各个实例建4个库（database）、各个库128张表（这里实质上是一个成本取舍的流程，理论上应该采取”多库少表”的准则，单库128张表其实太多了，单库建议32或64张表为宜）。 接下来如果实例压力提高可进行实例配置改进(16C/128G、32C/128G、32C/256G等)；将来如出现单实例升配无法解决，在考虑扩容实例，只需求将database迁移至新实例，迁移成本较小。 按单表最多1000w条数据评估，4096张表可支持日5000w单3年(10.1压测标准)、日2000w单5年的架构。（因业务表比较多，此处忽略掉单条数据大小的计算流程） 32个库，各个库128张表。将来可最大扩容到32个实例，无需rehash，只需求迁移数据。 阿里云RDS规格和价钱一览 因扩分库分表涉及到rehash流程（256表变4096表），而阿里云DTS只支持同构库数据迁移，所以我们基于DTS的binlog转kafka实力自研了数据同步中间件。 整体数据迁移工作包含：前期预备、数据同步环节（历史数据全量同步、增量数据实时同步、rehash）、数据校验环节（全量校验、实时校验、校验规章配置）、数据修复工具等。 在进行数据同步前，需求先整理一切表的惟一业务ID，只有确定了惟一业务ID才学兑现数据的同步操作。 需求重视的是： 一旦表中没有惟一索引，就会在数据同步流程中造成数据重复的危险，所以我们先将没有惟一索引的表依据业务场景增加惟一索引（有也许是联合惟一索引）。 在这里顺便提一下，阿里云DTS做同构数据迁移，应用的是数据库自增ID做为惟一ID应用的，这种情形如果做双向同步，会造成数据覆盖的问题。解决案例也有，之前我们的做法是，新旧实物采纳自增ID单双号解决，担保新旧实例的自增ID不会出现冲突就行。由于这次我们应用的自研双向同步组件，这个难题这里不细聊。 分表规章不同决定着rehash和数据校验的不同。需逐个表整理是用户ID纬度分表还是非用户ID纬度分表、是否只分库不分表、是否不分库不分表等等。 数据同步全局案例见下图，数据同步基于binlog，独立的中间服务做同步，对业务代码无侵入。 后续对每一个环节进行介绍。 单独一个服务，应用游标的方法从旧库分批select数据，通过rehash后批量插入（batchinsert）到新库，此处需求配置jdbc联结串参数rewriteBatchedStatements=true才学使批处理操作生效。 另外特殊需求重视的是，历史数据也会存在不断的更新，如果先开启历史数据全量同步，则刚同步达成的数据有也许不是最新的。所以这里的做法是，先开启增量数据单向同步（从旧库到新库），此时只是开启积压kafka消息并不会真正消费；然后在开始历史数据全量同步，当历史全量数据同步达成后，在开启消费kafka消息进行增量数据同步（提升全量同步效率变少积压也是核心的一环），这样来担保迁移数据流程中的数据一致。 增量数据同步考虑到灰度切流稳定性、容灾和可回滚实力，采纳实时双向同步案例，切流流程中一旦新库出现稳定性问题或者新库出现数据一致问题，可迅速回滚切回旧库，担保数据库的稳定和数据稳妥。 增量数据实时同步采纳基于阿里云DTS的数据订阅自研数据同步组件data-sync兑现，主要案例是DTS数据订阅实力会自动将被订阅的数据库binlog转为kafka，data-sync组件订阅kafka消息、将消息进行过滤、合并、分组、rehash、拆表、批量insert/update，最后再上交offset等一系列操作，最终达成数据同步工作。 整体流程中有几个问题需求重视： 问题1：怎样预防因异步消息无顺序而致使的数据一致问题？ 第一kafka异步消息是存在顺序问题的，可是要知道的是binlog是顺序的，所以dts在对具体进行kafka消息投递时也是顺序的，此处要做的就是一个库担保只有一个顾客就能保障数据的顺序问题、不会出现数据状态覆盖，从而解决数据一致问题。 问题2：是否会有丢消息问题，假如顾客服务重启等情形下？ 这里没有采纳自动上交offset，而是每次消费数据最终入库达成后，将offset异步存到一个mysql表中，如果顾客服务重启宕机等，重启后从mysql拿到最新的offset开始消费。这样惟一的一个问题也许会出现瞬间部分消息重复消费,可是由于上面介绍的binlog是顺序的,所以能担保数据的最终一致。 问题3：update转insert会不会丢字段？ binlog是全字段发送,不会存在丢字段情形。 问题4：循环消息问题。 后面进行单独介绍。 前文有提到，由于是256表变4096表，所以数据每一条都需求通过一次rehash重新做分库分表的计算。 要说rehash，就必须先介绍下目前订单数据的分库分表策略，订单ID中冗余了用户ID的后四位，经过用户ID后四位做hash计算确定库号和表号。 数据同步流程中，从旧库到新库，需求拿到订单ID中的用户ID后四位模4096，确定数据在新库中的库表位置；从新库到旧库，则需求用用户ID后四位模256，确定数据在旧库中的库表位置。 想象一下，业务写一条数据到旧实例的一张表，于是诞生了一条binlog；data-sync中间件接到binlog后，将该记载写入到新实例，于是在新实例也诞生了一条binlog；此时data-sync中间件又接到了该binlog……不断循环，消息愈来愈多，数据顺序也被打乱。 怎样解决该问题呢？我们采纳数据染色案例，只要能够标识写入到数据库中的数据使data-sync中间件写入而非业务写入，当下次接收到该binlog数据的时候就不必进行再次消息流转。 所以data-sync中间件需求，各个数据库实例创建一个事务表，该事务表tb_transaction只有id、tablename、status、create_time、update_time几个字段，status默认为0。 再回到上面的问题，业务写一条数据到旧实例的一张表，于是诞生了一条binlog；data-sync中间件接到binlog后，如下操作： 此时data-sync中间件将上面这些语句打包全体上交到新实例，新实例更新数据后也会生产对应上面语句的binlog；当data-sync中间件再次接收到binlog时，只要推断碰到tb_transaction表status=1的数据开始，后面的数据都直接舍弃不要，直到碰到status=0时，再陆续接收数据，以此来担保data-sync中间件只会流转业务诞生的消息。 数据校验模块由数据校验服务data-check模块来兑现，主要是基于数据库层面的数据对照，逐条核对每一个数据字段是否一致，不一致的话会通过配置的校验规章来进行重试或者报警。 通过数据校验，一旦发觉数据不一致，则需求对数据进行修复操作。 数据修复有两种案例，一种是适用于大范围的数据不一致，采纳重置kafkaoffset的方法，重新消费数据消息，将有问题的数据进行覆盖。 全局灰度案例：SP+用户纬度来兑现，SP纬度：凭仗灰度情境切量来做，用户纬度：依靠用户ID后四位百分比切流。 灰度切量的流程肯定要配合停写（秒级），为什么要停写，由于数据同步存在肯定拖延（正常毫秒级），而一切业务操作肯定要保障都在一个实例上，否则在旧库中业务刚刚调整了一条数据，此时切换到新库如果数据还没有同步过来就是旧数据会有数据一致问题。所以流程应该是： 虽然在切流之前，在测试情境进过了大量的测试，可是测试情境毕竟和生产情境不相同，生产情境数据库一旦出问题就也许是灭顶之灾，虽然上面介绍了数据校验和数据修复步骤，可是把问题拦截在发生之前是做服务稳定性最重大的工作。 因此我们提出了ABC验证的概念，灰度情境ABC验证预备： 详细灰度案例和数据源切换步骤： 整体数据迁移流程还是比较复杂的，时光也不是非常充裕（流程中还穿插着十一全链路压测改变），在有限的时光内集大家之力重复探讨发掘也许存在的问题，然后论证解决案例，不放过任何一个也许出现问题的环节，还是那句话，把问题拦截在发生之前是做服务稳定性最重大的工作。 流程中的细节还是非常多的，从数据迁移的预备工作到数据同步测试，从灰度步骤确定到正式生产切换，尤其是融合业务和数据的特色，有非常多需求考虑的细节，文中没有一一列出。 最终通过近两个月的紧张工作，无业务代码侵入、零事故、平稳地达成了扩分库分表和数据迁移的工作。
唯一小编 2021-03-01 阿里云服务器
腾讯云Terraform初始化 改进terraform到v0.13后，初始化terraform也许会出现以下问题 因素是terraform自v0.13后就交给provider自己维持了。解决案例： 1.应用命令查看自己版本 示例得到 +provider.tencentcloudv1.53.0 2.粘贴以下代码至terraform配置中，version采纳自己的tencentcloudterraform版本
唯一小编 2021-03-01 腾讯云服务器
阿里云无服务器高弹性的架构 在网络相关的业务中，高弹性是往往被提及的一个架构设计目的，前两个我就碰到一个用户需求我们帮助设计一个高弹性的架构以承载他们周期性暴增的业务压力，用户90%以上的业务压力都集合在业务高峰期，因此在设计这个架构之初，我和用户就在纠结，到底是采纳更了解的“堆”服务器的想法呢，还是采取更具弹性的容器化的案例呢？其实作为一个技术人员，在问这个难题的时候就已经有确定的答案了，最终我们设计出了这样的一个架构： 容器平台选择阿里云的ACK（阿里云容器服务Kubernetes版）。其中ACK分成专有版和托管版，区分是专有版的管控节点需求用户自行预备，而托管版应用阿里云的资源进行资源管控，在托管版中又分成标准版和Pro版，其中Pro版有确定的SLA保障，生产系统建议选择Pro版。同时为了保障worker节点的内容安全，建议为充当worker节点的ECS配置云安全中心服务进行主机安全防护。 除了ACK，阿里云还提供无服务器架构的ASK，区分是ACK有ECS服务器充当worker节点，创建POD所需的资源经过ECS进行安排，而ASK没有worker节点，ASK直接在阿里云的分享资源池中经过ECI（弹性容器节点）来安排资源创建POD。 在这个项目中为了担保永远有肯定量的稳定资源供给，我们决定应用ACK再融合阿里云的ECI来兑现资源的弹性供给。ECI资源的申请和释放可经过ACK的ack-virtual-node插件出自动达成，动态增加的POD将自动运行在ECI之上。 考虑到业务高峰期和平常存在庞大的应用量落差，选择应用按流量的方法购入手互联网带宽资源，并经过购入手分享流量包将一切的互联网流量进行集合抵扣。这个项目所用到的互联网流量主要有如下三个： 鉴于ECI节点上服务的启动需求肯定的时光，而业务流量也许瞬间到达峰值，因此经过MQ来缓冲瞬时的业务压力，为运行在ECI弹性资源上的服务争取启动时光。 阿里云MQ服务依据访问协议的不同分成RocketMQ、AMQP、Kafka三个系列，对于海量的业务交易场景建议选择通过双十一检验的RocketMQ系列，在RocketMQ系列中又分成一般版和公司铂金版两个版本，公司铂金版采纳独享硬件资源，能够更充分的保障峰值吞吐实力，对于瞬时业务峰值高的业务，建议尽也许选择铂金版。 数据库采纳云原生数据库PolarDB，PolarDB可以从2个节点扩容到16个节点，单节点可改进至88核710G规格，集群采纳分布式分享存储架构，单个集群可存储100TB的数据，有赖于其采纳分布式分享存储的架构，PolarDB集群增加节点时无需进行大量的数据拷贝，因此可以在分钟级达成集群的横向扩容。 我觉得这个架构对于大部分“腰部”级其他网络行业用户都是适用的，因此共享出来，盼望对大家有所协助。
唯一小编 2021-03-01 阿里云服务器
云专线和普通专线区别 云专线和普通专线区别，首先我们说一下云专线在定义和应用方 面的区别。 普通物理专线，是端口带宽资源被用户独占的物理专线，此种类型的物理专线由用户单独使用该物理线路，专线用户可以创建多个虚拟接口。 云专线(Direct Connect)用于搭建用户本地数据中心与云上VPC之间高速、低时延、稳定安全的专属连接通道。 传统专线主要应用于用户的局域网互联或快速浏览互联网。用户可以根据需要选择64Kbps- 2Mbps不等的速率。通过互联专线实现数据、语音、图像等业余的安全传输:实现各公司、部门间的资源交换和共享;通过拥有固定、独享的IP地址,视需要建立自己的Mail-Server. Web- Server等服务器,并可通过Internet组建公司内部的VNP业务。 云专线是连接客户局域网与行业云的专线网络,全程独立通道,能够不经互联网连接云主机,同时能保证高网速,对于银行、金融机构等高保密性要求的客户具有重要意义。 下面,我们在分别从开通时间、费用、弹性伸缩、稳定性等维度对他们之间的区别进行说明: 对比一下可以发现 , VPN是开通便捷,费用上比云专线要低很多,但是在公网的质量保障上不如专线,时延高,安全性不如云专线强。相对来说云专线低时延、服务质量稳定,但是在费用上就较高一些。而且在开通时间上,因为受限于物理专线的部署、运营商的线路资源的情况,所以部署时间要比VPN长。在这个情况下,一个量级, VPN如果双方都有internet资源的话,基本上是即开即用,双方配置好,协商起来就可以通信。但是云专线一般是将数据中心和公有云VPC对接,这个时候受限于物理链路,要运营商去核查资源,要去做物理线路的对接。这些正常情况下,就运营商的承诺。有诺的时间一般都是至少需要20个工作日。云专线线上的配置开通,现在一般也是天级,在拿到这种线路配置信息,且物理专线对接完以后,在一天内就可以完成这个线路配置打通的。 唯一网络是中国市场专业的云托管服务商( Cloud MSP ),在数据中心和云计算领域有近十年的专业交付和管理经验,目前正服务于2000多家企业级客户并与全球多家超大规模公有云服务商建立了战略合作关系。在云计算驱动产业变革的今天,安畅以客户需求为驱动,积极投资于核心技术研发和团队组织的云原生技能,致力于成为IT新生态和产业互联网的新-代连接器。 为客户提供”云+大数据+AI”的咨询、集成和管理服务,以及数字化解决方案,帮助客户利用新技术进行业务创新,实现数字化变革。
唯一小编 2021-02-19 专线