更新于:12-15 23:30

有关[设计]分类推荐

从 Feign 使用注意点到 RESTFUL 接口设计规范 - ImportNew

于12-11 09:01 - -
最近项目中大量使用了Spring Cloud Feign来对接http接口,踩了不少坑,也产生了一些对RESTFUL接口设计的想法,特此一篇记录下. SpringMVC的请求参数绑定机制. 了解Feign历史的朋友会知道,Feign本身是Netflix的产品,Spring Cloud Feign是在原生Feign的基础上进行了封装,引入了大量的SpringMVC注解支持,这一方面使得其更容易被广大的Spring使用者开箱即用,但也产生了不小的混淆作用.

[转]万亿级调用系统:微信序列号生成器架构设计及演变

于12-09 08:45 - wzzfeitian -
“每天万亿级调用的重量级系统,每次申请序列号平时调用耗时1ms,99.9%的调用耗时小于3ms,服务部署于数百台4核CPU服务器上. 曾钦松,微信高级工程师,目前负责微信后台基础服务、朋友圈后台等开发优化,致力于高可用高性能后台系统的设计与研发. 2011年毕业于西安电子科技大学,早先曾在腾讯搜搜从事检索架构、分布式数据库方面的工作.

基于分布式环境下限流系统的设计

于11-18 03:00 - - Redis 流控
就拿前些天的双十一的 “抢券活动” 来说,一般是设置整点开始抢的,你想想,淘宝的用户群体非常大,可以达到亿级别,而服务接口每秒能处理的量是有限的,那么这个时候问题就会出现,我们如何通过程序来控制用户抢券呢,于是就必须加上这个限流功能了. 1、服务接口所能提供的服务上限(limit)假如是 500次/s.

基于Redis的限流系统的设计

于11-18 01:51 - -
基于Redis的限流系统的设计,主要会谈及限流系统中. 限流策略这个功能的设计;在实现方面,算法使用的是. 令牌桶算法来,访问Redis使用lua脚本. rate limiting is used to control the rate of traffic sent or received by a network interface controller and is used to prevent DoS attacks.

一个完整推荐系统的设计实现-以百度关键词搜索推荐为例

于09-17 14:42 - admin - 产品 推荐系统 搜索引擎 数据挖掘 机器学习
在之前一篇博文中, 有同学在评论中问了个问题: 如何解决因式分解带来的推荐冷门,热门关键词的问题. 在回答这个问题的时候, 想到了近几年在做搜索推荐系统的过程中, 学术界和工业界的一些区别. 正好最近正在做技术规划, 于是写偏文章说下工业界完整推荐系统的设计. 结论是: 没有某种算法能够完全解决问题, 多重算法+交互设计, 才能解决特定场景的需求.

互联网架构,如何进行容量设计?

于10-23 03:31 - -
互联网公司,这样的场景是否似曾相识:. 场景一:pm要做一个很大的运营活动,技术老大杀过来,问了两个问题:. (2)如果扛不住,需要加多少台机器. 场景二:系统设计阶段,技术老大杀过来,又问了两个问题:. (2)如果需要分库,需要分几个库. 技术上来说,这些都是系统容量预估的问题,容量设计是架构师必备的技能之一.

【漫谈数据仓库】 如何优雅地设计数据分层

于10-19 06:03 - -
本文主要讲解数据仓库的一个重要环节:如何设计数据分层. 其它关于数据仓库的内容可参考之前的文章. 本文对数据分层的讨论适合下面一些场景,超过该范围场景or数据仓库经验丰富的大神就不必浪费时间看了. 数据建设刚起步,大部分的数据经过粗暴的数据接入后就直接对接业务. 数据建设发展到一定阶段,发现数据的使用杂乱无章,各种业务都是从原始数据直接计算而得.

RESTful API 设计最佳实践

于10-16 13:48 - 十七树 - IT技术 restful
项目资源的URL应该如何设计. 用哪种HTTP方法来创建一个新的资源. 实现分页和版本控制的最好方法是什么. 因为有太多的疑问,设计RESTful API变得很棘手. 在这篇文章中,我们来看一下RESTful API设计,并给出一个最佳实践方案. 资源集合用一个URL,具体某个资源用一个URL:. #资源集合的URL /employees/56.

从业 6 年走了不少弯路,我分享下如何自学成为一名合格的设计师

于10-15 00:09 - -
做设计师 6 年,从集团企业到初创企业,从网页设计师到资深视觉设计师再到设计总监,再到今天的独立设计师,经历了不同组织架构公司中的不同设计职位,整个过程中可以说一直都在自学. 这个过程当中也走过一些弯路,希望能够通过我的一些经验和思考,给题主或是对设计感兴趣、想要从事设计工作的人一些帮助. 首先,我认为有必要先提几点常见的对设计的误解,在对设计有一个较为正确的认识之后,才谈上的如何学习设计.

用JAVA如何实现每天1亿条记录的数据存储,数据库方面怎么设计?

于10-11 12:26 - linder -
一天秒数:60*60*24=86,400秒. 每天写入数据量:100,000,000条. 平均每秒写入数据量:100,000,000/86,400=1157.5条. 峰值每秒估算写入数:1157.5*10=11575条. 因此建议从以下几个层面处理. 1、数据库服务器磁盘采用高速SSD磁盘. 2、数据库采用2个节点的集群方式部署,每个集群节点3台服务器,1主2备,主数据库为写数据库,备数据库为读数据,采用读写分离,单集群节点内主备库数据实时同步,集群节点主库数据实时同步.

ActiveMQ架构设计与最佳实践

于06-12 17:08 - -
    ActiveMQ是最常用、特性最丰富的消息中间件,通常用于消息异步通信、调用解耦等多种场景,是JMS规范的实现者之一.     ActiveMQ提供两种可供实施的架构模型:“M-S”和“network bridge”;其中“M-S”是HA方案,“网络转发桥”用于实现“分布式队列”.     Master-Slave模型下,通常需要2+个ActiveMQ实例,任何时候只有一个实例为Master,向Client提供"生产"、“消费”服务,Slaves用于做backup或者等待Failover时角色接管.

运营支撑系统(BSS)在面向物联网IoT业务场景的模型简要分析和设计

于09-17 13:33 - lottons88 -
BSS运营支撑系统(主要指电信运营商),通常都是为了支撑个人客户的业务运营. 虽然在业务运营上也面向集团客户,但是总体上来说,业务的特性总结归纳为2C的业务场景. 而当前运营商在面向物联网的业务运营下,主要是以2B的业务场景. 运营商实际并不会直接面向最终的客户,而是通过其他业务的运营企业的合作或者买卖关系提供,即是一种B2B2C的场景.

深入解析Kafka高可用设计如何步步为营

于09-08 00:00 - - bigdata
Kafka在0.8以前的版本中,并不提供High Availablity机制,一旦一个或多个Broker宕机,则宕机期间其上所有Partition都无法继续提供服务. 若该Broker永远不能再恢复,亦或磁盘故障,则其上数据将丢失. 而Kafka的设计目标之一即是提供数据持久化,同时对于分布式系统来说,尤其当集群规模上升到一定程度后,一台或者多台机器宕机的可能性大大提高,对于Failover机制的需求非常高.

哔哩哔哩大数据采集服务—Lancer系统设计与实践

于09-06 05:34 - -
        哔哩哔哩(以下简称B站)的日志采集肩负了B站的所有业务的日志收集并传输,提供离线数据和实时数据以满足离线或实时计算以及业务方订阅的需求. B站日志收集系统是基于Flume设计和搭建而成的.        数据采集是大数据的基石,近几年随着业务的高速增长,产生的数据量越来越大,并且会持续快速增长.

如何为技术博客设计一个推荐系统(中):基于 Google 搜索的半自动推荐

于09-05 12:55 - Phodal Huang - 杂谈
与统计学相比,基于内容来向用户推荐相似的内容,往往更容易获得. 在技术领域,作者通常比大多数读者更专业,他们往往知道什么是读者需要的. 如,你看了一个 React 相关的文章,你可能会需要 Redux 相关的内容. 需要一些前提条件:融合现有系统的数据信息,获取一些用户的信息. 随后,再计算出相关的内容,最后返回给读者.

前后端完全分离之API设计

于04-18 09:46 - - Java Javascript Rest 架构
我的目标不仅是能用,而且好用, 跨平台(PC, Android, IOS, etc…)使用; 本文将详细介绍API的设计及异常处理, 并将异常信息进行封装友好地反馈给前端.. 上篇文章 前后端完全分离初探只是讲了些宽泛的概念, 接下来的文章将直接上干货, 干货的源码会挂在 github上.. 前后端完全分离后, 前端和后端如何交互.

“本地缓存”架构设计

于08-17 11:16 - -
最近在做的项目其实是对老系统的一个深度改造,在老系统里缓存使用这块感觉有些瑕疵. 在老系统里不管是“配置数据”还是“业务数据”都统一使用redis作为缓存. “业务数据”使用redis作为缓存无可厚非,但“配置数据”使用使用redis就感觉不是很妥. 首先:过渡依赖redis,一些开关配置都依赖redis,如果redis服务挂掉整个服务瘫痪;.

支付网关的设计 - 凤凰牌老熊的博客 | Shamphone Blog

于08-09 12:42 - -
在支付系统中,支付网关和支付渠道的对接是最核心的功能. 其中支付网关是对外提供服务的接口,所有需要渠道支持的资金操作都需要通过网关分发到对应的渠道模块上. 一旦定型,后续就很少,也很难调整. 而支付渠道模块是接收网关的请求,调用渠道接口执行真正的资金操作. 每个渠道的接口,传输方式都不尽相同,所以在这里,支付网关相对于支付渠道模块的作用,类似设计模式中的wrapper,封装各个渠道的差异,对网关呈现统一的接口.

从简书iOS客户端,来谈谈Hybrid方案细节设计 - 简书

于08-07 05:43 - -
作为一位 iOS 开发人员,你应该已经敏感地发现,自己的工作涉及内容已经不止于 Native 的部分,因为 Hybrid App 和 ReactNative 等技术方案已经不仅仅是概念,越来越多的公司开始着手自己的 Hybrid 方案以及 ReactNative 本地化工作. 介绍相关概念的优秀文章已经有许多,方案的实现原理你也应该已经或多或少有了一些理解.

异地多活架构设计 - 博客频道 - CSDN.NET

于07-31 12:58 - -
有幸参与了阿里游戏的一个高可用方案的设计,并且在网上发表了方案(面向业务的立体化高可用架构设计),后来参加GOPS全球运维大会深圳站,与众多行业高手交流,发现大家对“异地多活”这个方案设计非常感兴趣,毕竟“异地多活”的方案价值非常大,尤其是互联网行业,规模稍微大一点几乎都必须是标配;但同时大家都觉得“异地多活”的方案设计又很难,网络、数据、事务等各种问题混杂在一起,很多问题看似是无法解决的.

企业级 API 网关的设计

于06-24 00:00 - - dev
转载本文需注明出处:微信公众号EAWorld,违者必究. 三、企业级API网关需要具备的条件. 四、业界常用的API网关方案. 五、如何设计一个好的企业级API网关产品. API Gateway(APIGW / API 网关),顾名思义,是出现在系统边界上的一个面向API的、串行集中式的强管控服务,这里的边界是企业IT系统的边界,主要起到隔离外部访问与内部系统的作用.

漫谈数据仓库之拉链表(原理、设计以及在Hive中的实现)

于05-12 00:00 - - bigdata
本文将会谈一谈在数据仓库中拉链表相关的内容,包括它的原理、设计、以及在我们大数据场景下的实现方式. 先分享一下拉链表的用途、什么是拉链表. 通过一些小的使用场景来对拉链表做近一步的阐释,以及拉链表和常用的切片表的区别. 举一个具体的应用场景,来设计并实现一份拉链表,最后并通过一些例子说明如何使用我们设计的这张表(因为现在Hive的大规模使用, 我们会以Hive场景下的设计为例).

腾讯ISUX→UI设计师急需掌握的平面设计基础

于02-07 03:43 - jackchen - Photoshop UI UX 设计教程
曾看到网上一些帖子讨论UI设计师和平面设计师的差异,总结为思维方式的不同: UI设计师考虑用户习惯和易用体验,平面设计师专注于更具吸引力的信息传达. 两者侧重不同但专业上有非常大的交集,信息传达的核心基础技能其实都是相通的. 平面设计是如何表达一个事物,而UI设计是如何让用户更好使用一个事物,表达层面令人费解则卡在了使用的第一步.

表单设计优化

于11-13 13:32 - 可乐橙 -
设计师常犯的错误,以及正确做法. 无论是注册流程、多屏分步表单,或者是单调的数据列表界面,表单都是数字产品设计中的重要组成部分. 记住这些只是通用规范,每条准则总有例外. 多列布局会扰乱用户垂直方向的视线移动. 顶部标签的表单比左侧标签有更高的完成率. 顶部标签的表单也易于移植到移动端. 但是,对于有多种选择项的大量数据列表而言,请考虑使用左侧标签,因为它们在一起更易于浏览,能够减少高度,比顶部标签更贴心.

交互设计师如何做竞品分析

于11-13 18:36 - shendao - 极客互联
今天我们来聊聊竞品分析,它并不是像人们认为的那样——有统一的模板,因为针对不同的岗位,做的竞品分析是不同的. 所以我的文章标题是: 交互设计师如何做竞品分析. 竞品分析是对产品、交互从业人员最基本的技能要求之一,很多刚入行的产品汪、交互喵首先要做的都是竞品分析,一来可以考考你的底子,二来可以锻炼你的逻辑思维.

携程:上万坐席呼叫中心异地双活架构及系统设计

于12-05 03:10 - 小码哥 - 他山之石 异地双活架构 携程
携程旅行网  通信技术中心高级经理. 拥有十几年的呼叫中心系统建设和运维管理经验,经历了携程呼叫中心系统架构的多次转型设计,使之从单一系统逐步演进到异地冗灾、异地双活,从单品牌到多平台的融合架构设计. 目前负责携程上万座席呼叫中心的产品管理和架构设计工作. 之前,我先拜读了《Google SRE》 这本书的几个章节,我对这些章节中的内容非常认同,特别是基于自动化运维以及故障响应时间的阐述,感同身受.

干货!所有常用的原型设计工具都在这里了

于11-22 10:05 - -
本文列举了20余款当前国内外比较火爆的原型设计工具. 交互原型设计工具(仅限页面交互). 动态原型工具(组件和页面交互). 交互原型设计工具(仅限页面交互). 这一类工具主要是建立页面之间的交互. 其本身不能进行组件的制作和设计,需要从其它地方(例如:PS,本地)导入设计图,对已有的设计图创建热点,进行交互设计.

产品实例:某项目APP后台系统设计

于12-26 08:47 - 悠闲小生 - 产品设计 案例分析 经验分享
今年有幸参与了某度假屋项目从0到1的设计过程,展示给用户的是精致的APP,然而APP背后却是逻辑比较复杂的后台系统. APP的使用体验,很大程度上是由后台系统决定的,后台系统逻辑的合理性决定了APP的核心流程. 简要介绍一下此项目的业务流程如图1所示:. 业主购买度假屋并由物业管理公司托管,业主购买度假屋有三种类型:全套、分权、分时,全套即业主购买整套度假屋,分权即业主购买度假屋部分产权,分时即业主购买某季的居住权.

Typecho的数据库设计的学习

于12-26 04:19 - 标点符 - 程序开发 数据库
Typecho是一款仿Wordpress,但相对Wordpress要简单的多的开源博客程序. 开发者大量的参考了WordPress的设计,去除了一些高级复杂的功能,实现了一个小而美的博客系统. 轻量高效:仅仅 7 张数据表,加上不足 400KB 的代码,就实现了完整的插件与模板机制. 超低的 CPU 和内存使用率,足以发挥主机的最高性能.

[原]增量接口的设计及实现

于03-20 08:45 - ghsau -
在应用开发过程中,我们总会碰到这样的场景:某系统需要同步我们系统的数据去做一些业务逻辑,当数据量较小的时候,可以全量的提供,但当数据量很大时,全量提供就显得很笨重,不仅耗时而且做了很多无用功,这时我们需要一种提供增量数据的机制,只告诉对方变化的数据. 提供增量数据大致可分为两种方式:MQ和接口提供,MQ的优点是及时,缺点是丢失、重复、回溯复杂等等问题(依赖于具体MQ实现),这里不过多赘述;接口提供不限于RPC或HTTP等方式,接口提供的优缺点正好和MQ反过来,及时性取决于调用周期.