Tair

简介： 闲鱼flutter faas一体化提升研发体验+研发质量 作者：闲鱼技术-古风 Flutter+Serverless三端一体研发架构，客户端不仅仅是编写双端的代码，而是扩展了客户端的工作边界，形成完整的业务闭环。在新的研发模式落地与实践的过程中，一直在思考如何提高FaaS端研发体验与研发质量，以下是落地过程中遇到的问题。 如何提高FaaS研发体验？ FaaS层通常是直接在主干中逐块增加业务代码，这种写法领域数据间的依赖并不清晰，后续维护时需要针对领域数据进行更换、顺序调整或者由串行改并行时需要增加很多工作。 如何提高FaaS侧研发质量？ 客户端同学编写FaaS代码时，需要针对服务端各种异常增加保护性代码与降级策略，比较容易出现遗漏从而导致整体质量下降。 任务编排是什么？ 回顾一个完整的业务闭环，包括中台、领域层、业务层与渲染层。云端一体场景下FaaS侧更多的工作集中在业务层与渲染层，进行数据聚合、裁剪、字段映射和结构调整。 以下单业务为例，FaaS层通过6次HSF（RPC框架）调用获取领取数据组装而成。商品信息、收货地址与闲鱼币可以并行执行，红包、运费与验货担保可以并行执行，由于依赖商品信息与收货地址，两组任务需要串行执行。 上图中可以把每一个节点（例如：获取商品信息）抽象为任务，通过代码实现此流程就是任务编排。 任务编排如何提升开发体验？

阿里云数据库专属集群专属链接 云专属数据库，重新定义云数据库新形态 数据库是一个有着超过40年历史的悠久行业，前期一直被传统的如Oracle等少数几家厂商把持。云计算的先行者AWS在2009年率先推出RDS服务（Relational Database Service ），商业上通过云计算的模式颠覆了传统license交付的模式，产品上通过全托管的服务模式，在技术和产品上帮助客户代维数据库，颠覆了客户自运维的模式，降低了客户使用数据库的门槛，使得客户聚焦到业务本身，生产力得到了极大的提高。 阿里云作为国内云数据库的领导者，在2010年推出了阿里云RDS服务，经过10年的发展，阿里云RDS已经发展成为了一个完整的价值体系，支持MySQL、MariaDB、SQL Server、PostgreSQL等，并由此发展出来一系列NoSQL、OLAP、工具等产品。今天的阿里云数据库已经名列全球云数据库Top 3，比肩AWS和Azure等国际重量级玩家。 当前上云已经成为一种趋势，而在上云的过程中，数据库则被认为是非常重要的一环。越来越多的中大型客户，尤其是在传统行业中，客户在线下或者云上自建数据库，有自己使用数据库的习惯、熟悉的工具集和监控运维体系，如何在提供便捷、灵活的云数据库服务的同时，兼顾企业客户对于数据库自主可控制、安全合规性诉求，使得客户能够对接现有的监控运维体系、数据库专业工具。这一次

一、什么样的数据适合缓存 二、缓存穿透 缓存穿透是指查询一个一定不存在的数据，由于缓存是不命中时需要从数据库查询，查不到数据则不写入缓存，这将导致这个不存在的数据每次请求都要到数据库去查询，造成缓存穿透。在流量大时，可能DB就挂掉了，要是有人利用不存在的key频繁攻击我们的应用，这就是漏洞。 解决方案： 1）有很多种方法可以有效地解决缓存穿透问题，最常见的则是采用布隆过滤器，将所有可能存在的数据哈希到一个足够大的bitmap中，一个一定不存在的数据会被这个bitmap拦截掉，从而避免了对底层数据库的查询压力。 2）另外也有一个更为简单粗暴的方法，如果一个查询返回的数据为空（不管是数据不存在，还是系统故障），仍然把这个空结果进行缓存，但它的过期时间会很短，最长不超过五分钟。 三、缓存雪崩： 缓存雪崩是指在设置缓存时采用了相同的过期时间，导致缓存在某一时刻同时失效，导致所有的查询都落在数据库上，造成了缓存雪崩。 解决方案： 1）在缓存失效后，通过加锁或者队列来控制读数据库写缓存的线程数量。比如对某个key只允许一个线程查询数据和写缓存，其他线程等待。 2）可以通过缓存reload机制，预先去更新缓存，在即将发生大并发访问前手动触发加载缓存。 3）不同的key，设置不同的过期时间，让缓存失效的时间点尽量均匀。 4）做二级缓存，或者双缓存策略。A1为原始缓存，A2为拷贝缓存，A1失效时

面对一个完全陌生的系统，如何快速的熟悉并上手?本文将从三个方面进行总结，提供一个系统的方法，同时也可以用来 review 已有的系统，查漏补缺。 面对一个完全陌生的系统，如何快速的熟悉并上手?面对一个完全陌生的系统，如何快速的熟悉并上手? 前言 开发人员经常会面临下面一些场景： 新人入职，需要学习已有系统，作为 landing 的一部分，如何学习? 被拉过去参与一个陌生系统的迭代开发或者系统维护(bugfix)，如何快速上手? 同事离职或转岗，需要把系统交接给你，怎么去接?内心 os：这是一口锅吗? 这样的场景多了，就需要去梳理常见问题以及应对方法，方便后续遇到类似场景可以快速应对。本文总结熟悉系统主要分三部分：业务学习、技术学习、实战。每部分会梳理一些在学习过程中需要解答的问题，这些问题随着经验的积累需要逐步补充完善。 业务学习 业务学习就是从业务角度去学习系统，我们需要了解系统的客户是谁、使用人是谁、带来了什么价值，系统提供了哪些功能等。不清楚业务，就等于不知道系统在干什么。技术是为业务落地而服务，清楚了业务才知道怎样用技术更好地服务业务，所以业务学习是熟悉一个系统的首要任务。这块主要的学习方式有跟产品、运营、开发沟通，学习产品设计文档文档、PRD、自己使用系统，还有一些常见图，如产品功能架构图、业务流程图、功能树，用例图等。 常见问题： 系统所在行业的情况是怎样?

面对一个完全陌生的系统，如何快速的熟悉并上手?本文将从三个方面进行总结，提供一个系统的方法，同时也可以用来 review 已有的系统，查漏补缺。 前言 开发人员经常会面临下面一些场景： 新人入职，需要学习已有系统，作为 landing 的一部分，如何学习? 被拉过去参与一个陌生系统的迭代开发或者系统维护(bugfix)，如何快速上手? 同事离职或转岗，需要把系统交接给你，怎么去接?内心 os：这是一口锅吗? 这样的场景多了，就需要去梳理常见问题以及应对方法，方便后续遇到类似场景可以快速应对。本文总结熟悉系统主要分三部分：业务学习、技术学习、实战。每部分会梳理一些在学习过程中需要解答的问题，这些问题随着经验的积累需要逐步补充完善。 业务学习 业务学习就是从业务角度去学习系统，我们需要了解系统的客户是谁、使用人是谁、带来了什么价值，系统提供了哪些功能等。不清楚业务，就等于不知道系统在干什么。技术是为业务落地而服务，清楚了业务才知道怎样用技术更好地服务业务，所以业务学习是熟悉一个系统的首要任务。这块主要的学习方式有跟产品、运营、开发沟通，学习产品设计文档文档、PRD、自己使用系统，还有一些常见图，如产品功能架构图、业务流程图、功能树，用例图等。 常见问题： 系统所在行业的情况是怎样? 系统的目标用户是谁?比如是给公司高层做决策用?给运营或客服用?还是互联网用户用? 平均有多少人在使用

面对一个完全陌生的系统，如何快速的熟悉并上手?本文将从三个方面进行总结，提供一个系统的方法，同时也可以用来 review 已有的系统，查漏补缺。 前言 开发人员经常会面临下面一些场景： 新人入职，需要学习已有系统，作为 landing 的一部分，如何学习? 被拉过去参与一个陌生系统的迭代开发或者系统维护(bugfix)，如何快速上手? 同事离职或转岗，需要把系统交接给你，怎么去接?内心 os：这是一口锅吗? 这样的场景多了，就需要去梳理常见问题以及应对方法，方便后续遇到类似场景可以快速应对。本文总结熟悉系统主要分三部分：业务学习、技术学习、实战。每部分会梳理一些在学习过程中需要解答的问题，这些问题随着经验的积累需要逐步补充完善。 业务学习 业务学习就是从业务角度去学习系统，我们需要了解系统的客户是谁、使用人是谁、带来了什么价值，系统提供了哪些功能等。不清楚业务，就等于不知道系统在干什么。技术是为业务落地而服务，清楚了业务才知道怎样用技术更好地服务业务，所以业务学习是熟悉一个系统的首要任务。这块主要的学习方式有跟产品、运营、开发沟通，学习产品设计文档文档、PRD、自己使用系统，还有一些常见图，如产品功能架构图、业务流程图、功能树，用例图等。 常见问题： 系统所在行业的情况是怎样? 系统的目标用户是谁?比如是给公司高层做决策用?给运营或客服用?还是互联网用户用? 平均有多少人在使用

前言 Hi，大家好，今天非常高兴能有机会作为讲师，来给大家分享关于《如何设计实现中后台搭建 PaaS 平台》这个话题。今天的分享将围绕阿里淘系技术部飞冰系列产品中的中后台搭建产品 iceluna 来进行展开。 个人介绍 在正式分享之前，先自我介绍一下。我是来自阿里淘系营销中后台团队的月飞，负责中后台搭建产品 iceluna，以及《阿里集团中后台搭建协议标准规范》的推广和落地。2013 年加入阿里巴巴聚划算，负责 PC & 无线详情。2016 年加入天猫，带领营销玩法团队，负责玩法、互动类型业务。2019 年加入淘系技术部，带领营销中后台团队，负责中后台业务，专注于中后台搭建产品建设。 话题介绍 今天的话题是搭建，以面向角色的不同大致可以分为面向运营和面向研发两类搭建产品。面向运营的搭建产品主要是以可视化配置 ( No-code ) 的方式进行完整页面搭建，如营销活动页面搭建。面向研发的搭建产品主要以低代码开发 ( Low-code ) 的方式，搭建“中后台系统”或者“无线模块”，如商家、小二后台系统的搭建，无线 Rax 模块的搭建。今天我这边的话题是中后台系统搭建，跟营销活动类页面的搭建在面向角色和搭建模式上是非常不同的，接下来主要围绕 “ iceluna 产品 ” 和 “ PaaS 平台建设 ” 2 个维度来展开分享。 分享大纲 这是我分享的大纲，我会先对 iceluna

作者 | 唐志龙（鲲龙） 阿里巴巴高级开发工程师 导读 ：本文总结了熟悉系统主要分三部分：业务学习、技术学习、实战。每部分会梳理一些在学习过程中需要解答的问题，这些问题随着经验的积累需要逐步补充完善。 前言 开发人员经常会面临下面一些场景： 新人入职，需要学习已有系统，作为 landing 的一部分，如何学习？ 被拉过去参与一个陌生系统的迭代开发或者系统维护（bugfix），如何快速上手？ 同事离职或转岗，需要把系统交接给你，怎么去接？ 内心 os：这是一口锅吗？ 这样的场景多了，就需要去梳理常见问题以及应对方法，方便后续遇到类似场景可以快速应对。本文总结熟悉系统主要分三部分：业务学习、技术学习、实战。每部分会梳理一些在学习过程中需要解答的问题，这些问题随着经验的积累需要逐步补充完善。 业务学习 业务学习就是从业务角度去学习系统，我们需要了解系统的客户是谁、使用人是谁、带来了什么价值，系统提供了哪些功能等。不清楚业务，就等于不知道系统在干什么。技术是为业务落地而服务，清楚了业务才知道怎样用技术更好地服务业务，所以业务学习是熟悉一个系统的首要任务。这块主要的学习方式有跟产品、运营、开发沟通，学习产品设计文档文档、PRD、自己使用系统，还有一些常见图，如产品功能架构图、业务流程图、功能树，用例图等。 常见问题： 系统所在行业的情况是怎样？ 系统的目标用户是谁？比如是给公司高层做决策用

导读 ：本文主要介绍了高德在服务单元化建设方面的一些实践经验，服务单元化建设面临很多共性问题，如请求路由、单元封闭、数据同步，有的有成熟方案可以借鉴和使用，但不同公司的业务不尽相同，要尽可能的结合业务特点，做相应的设计和处理。 一、为什么要做单元化 单机房资源瓶颈 随着业务体量和服务用户群体的增长，单机房或同城双机房无法支持服务的持续扩容。 服务异地容灾 异地容灾已经成为核心服务的标配，有的服务虽然进行了多地多机房部署，但数据还是只在中心机房，实现真正意义上的异地多活，就需要对服务进行单元化改造。 二、高德单元化的特点 在做高德单元化项目时，我们首先要考虑的是结合高德的业务特点，看高德的单元化有什么不一样的诉求，这样就清楚哪些经验和方案是可以直接拿来用的，哪些又是需要我们去解决的。 高德业务和传统的在线交易业务还是不太一样，高德为用户提供以导航为代表的出行服务，很多业务场景对服务的RT要求会很高，所以在做单元化方案时，尽可能减少对整体服务RT的影响就是我们需要重点考虑的问题，尽量做到数据离用户近一些。转换到单元化技术层面需要解决两个问题: 1.用户设备的单元接入需要尽可能的做到就近接入，用户真实地理位置接近哪个单元就接入哪个单元，如华北用户接入到张北，华南接入到深圳。 2.用户的单元划分最好能与就近接入的单元保持一致，减少单元间的跨单元路由。如用户请求从深圳进来

摘要 最初的秒杀系统的原型是淘宝详情上的定时上架功能，由于有些卖家为了吸引眼球，把价格压得很低。但这给的详情系统带来了很大压力，为了将这种突发流量隔离，才设计了秒杀系统，文章主要介绍大秒系统以及这种典型读数据的热点问题的解决思路和实践经验。 一些数据 大家还记得2013年的小米秒杀吗？三款小米手机各11万台开卖，走的都是大秒系统，3分钟后成为双十一第一家也是最快破亿的旗舰店。经过日志统计，前端系统双11峰值有效请求约60w以上的QPS ，而后端cache的集群峰值近2000w/s、单机也近30w/s，但到真正的写时流量要小很多了，当时最高下单减库存tps是红米创造，达到1500/s。 热点隔离 秒杀系统设计的第一个原则就是将这种热点数据隔离出来，不要让1%的请求影响到另外的99%，隔离出来后也更方便对这1%的请求做针对性优化。针对秒杀我们做了多个层次的隔离： 业务隔离。 把秒杀做成一种营销活动，卖家要参加秒杀这种营销活动需要单独报名，从技术上来说，卖家报名后对我们来说就是已知热点，当真正开始时我们可以提前做好预热。 系统隔离。 系统隔离更多是运行时的隔离，可以通过分组部署的方式和另外99%分开。秒杀还申请了单独的域名，目的也是让请求落到不同的集群中。 数据隔离。 秒杀所调用的数据大部分都是热数据，比如会启用单独cache集群或MySQL数据库来放热点数据，目前也是不想0.01