哇哦~

目前一些开放平台最常见的也就是hmac签名和oauth2.0的方式。另外secret的泄漏也是需要客户测去防范。平台方的ip白名单，以及客户端侧自己将授权和业务隔离 是比较好的方法。

类似于直方图，但它还会计算百分位数。直方图可以很好地展现时间序列数据，尤其适用于数据的可视化（如应用程序延迟等）。通常来说，单个指标对我们价值很小，往往需要联合并可视化多个指标，这其中需要应用一些数学变换。例如，我们可能会将统计函数应用于指标或指标组，一些可能应用的常见函数包括：·计数：计算特定时间间隔内的观察点数。·求和：将特定时间间隔内所有观察点的值累计相加。·平均值：提供特定时间间隔内所有值的平均值。·中间数：数值的几何中点，正好50％的数值位于它前面，而另外50％则位于它后面。

但是用于企业开发，企业是经常有人员流动，restful是不太好用的，因为每个人对restful的理解又不一样，又或者有的人根本没用过，这就导致很多接口很不合理，导致变得四不像，增加沟通成本，不如不用。此时依旧需要按路由去正则，把是同一个路由的，但是path里面的变量不一样的要归纳成一组，这又要写很多代码。1.用go解析路由时，中间件里相对路由做统一处理，或者是对于一组路由做处理，只能挨个正则去匹配。再比如restful其中之中的一点就是path里面用变量，在沟通，以及后端处理过程中都是比较麻烦的。

嵌入在应用程序中的组件，实现了将业务决策从应用程序代码中分离出来，并使用预定义的语义模块编写业务决策。作为开发人员会遇到需求变动的情况，比如if a >b then c改成 if a < b then c又要改成 if a

目前只做了用户账号间的数据隔离。存在情况，同一个项目里不同人创建不同的资源，项目里的成员都可以看得到，同时也不能互相随便修改数据。所以需要一些组的权限控制。

背景目前在某厂又开始了php，哎，逃不掉的php。又碰上了优化季度，所以被分了2个接口优化下，要求达到3个9就行。 目前是2个九，嘿嘿，要求已经很低了是吧？但是php这个东西还是比较难搞的。基础实施比较差的，也没有服务化，像有的服务化做的好的，可以直接分布式链路追踪看出耗时在哪里。同时希望最小改动原则，成本尽可能的低，效果尽量早点体现出来。开始1.先弄清3个9是根据啥统计的对的，我们要达成目标，就先要知道目标是怎么统计的。后面我去问了下，发现是统计nginx的日志，非200的/200

supervisor一个开源的后台托管程序，在使用过程中可能是因为机器宕机，导致supervisor没有正常关掉，在执行sudosupervisorctl，想查看进程状态时，提示unix:///var/run/supervisor.sock no such file解决那么如何解决这个问题呢？需要执行三个命令即可sudo touch /var/run/supervisor.socksudo chmod 777 /var/run/supervisor.socksudo service .

订单系统的核心功能和数据必备的功能，包括但不限于如下：1.创建订单2.随着购物流程更新订单状态3.查询订单，包括用订单数据生成各种报表为了支撑这些必备功能，在数据库中，我们至少需要有这样几张表1.订单主表：也叫订单表，保存订单的基本信息2.订单商品表：保存订单中的商品信息3.订单支付表：保存订单的支付和退款信息4.订单优惠表：保存订单使用的所有优惠信息几个表之间的关系如下：订单主表和后面的几个子表都是一对多的关系，关联的外键就是订单主表的主键，也就是订单号。如

什么是jwt以及工作流程？可以看下面的链接http://blog.leapoahead.com/2015/09/06/understanding-jwt/JWT是否要设置过期？如果不设置过期的话，jwt一旦被中间人获取，就可以永远使用，服务端是无法分辨出来的，因为jwt的无状态特性。所以过期时间是要设置的，而且短些比较好。token过期了，理论上要跳到登录页面重新登录，重新换取token的。比如我们设置1小时过期，用户每过1小时就需要重新输入密码，是不是感觉很奇怪呢？讨论怎么处理之前

如果第一次接触秒杀，那你可能还不太理解，库存100件就卖100件，在数据库里减到0就好了，这有什么麻烦的？理论上是这样，但是具体到业务场景中，减库存就不是这么简单了例如，我们平常购物都是看到喜欢的商品然后下单，但并不是每个下单请求你都最后付款了。你说系统是用户下单了就算这个商品卖出去了，还是等到用火狐真正付款了才算卖出了呢？这的确是个问题。减库存有哪几种方式在正常的电商平台购物场景中，...

为什么要消峰？1.一般秒杀商品的数量都是固定的，超过商品数的请求，再多的请求过来也无用2.秒杀是瞬时的，对服务器压力太大，不必要的请求可以过滤掉常用的消峰的方法1.排队使用消息队列但是，如果流量峰值持续了一段时间达到了消息队列的处理上限，例如本机的消息积压到了存储空间的上限，消息队列同样也会被压垮，这样虽然保护了下游的系统，但是和直接把请求丢弃也没多大的区别除了mq...

架构原则——四要四不要1.数据要尽量少指用户请求的数据能少就少，请求的数据包括上传给系统的数据和系统返回给用户的数据（通常就是网页）。例如：我们可以简化秒杀页面的大小，去掉不必要的页面装修效果等等原因：减少网络消耗，服务端cpu编码等2.请求数要尽量少同样的降低网络请，另外，如果不同请求的域名不一样的话，还设及这些域名的DNS解析，可能耗时更久3.路径要尽量短所谓路径...

之前有写过mongodb不停机迁移库思路https://blog.youkuaiyun.com/qq_28119741/article/details/89482676但这次不仅是迁库，而且要重构代码，要搞一个新服务出来，db要迁移到新库中，要求不停机无故障，完成新服务上线和数据迁移，数据量是亿级别的。大概讲下业务场景：一个阅读数的功能，只有add，判断是否读过，如果没有计数+1，存储用的mongod...

上文说到定时任务，也要搬到新服务里面去。然后我就搬了。。。go func() {tick := time.Tick(time.second*30)for {select {case <-tick:...}}然后大佬看到了，说别照搬吧，要思考，你这样写，这个goroutine挂了怎么办？你这个的本质就是定时任务，可以引入定时任务组件，不用这样...

今天把新库里面的数据成功迁移完成，跑了一遍check的脚本，一共跑了两遍，每一遍都有几条数据不一致。由于无其他信息，只能按照大概的时间点，查遍所有日志调用旧服务的接口，看看是否还有请求，结果一条也没看到。又去检查了所有机器的配置文件和代码，查看是否有不一致的。结果也没有什么收获。这时候大佬来了查问题要用框架性思维旧库在写，有几种方法会写？1。是调接口2.是写库刚才你检...