-
编辑 删除
90行代码，搞定日志监控框架
上一篇《100行代码，搞定http监控框架》介绍了通用+可扩展的http监控平台的架构：监控平台层：调度监控项，通过后台管理监控项信息管理层：通过服务和后台维护集群，告警接收人，告警策略等信息告警发送层：通过接口发送邮件，短信，微信等消息创业型公司，如果没有上述完善的基础设施，可以简化为一个通用+可
-
编辑 删除
100行代码，搞定http监控框架
集群信息管理，员工信息管理，告警策略管理，几篇前戏已经铺垫足够，今天，分享如何用100行代码搞定一个可扩展，通用的http监控框架。一、常见的http监控玩法提问：有哪些常见http监控需求？回答：常见的http监控需求有两类：html页面监控返回json数据的http接口提问：常见的http监控怎
-
编辑 删除
多维度立体化监控，才是真的监控
前文介绍了通用+可扩展的http监控平台与log监控平台的架构：《通用+可扩展http监控平台/框架》《通用+可扩展log监控平台/框架》结果，评论里各种冷嘲热讽。监控这个topic本来有很多细节可以聊，既然大伙公司都做得比较完善，后续就不纠细节了，聊聊方向上的思考，架构上的设计。今天和大伙聊聊多维
-
编辑 删除
分级告警策略，人性化系统监控？
要介绍统一监控平台，得先从告警策略聊起，后续再聊不同维度监控的架构与实现细节。一、啥是告警？监控平台发现系统异常，向系统负责人发出文字（例如，邮件/短信），色彩（有些公司，编译不过，CI平台会亮红灯），声音（有些公司，有蜂鸣器嗡嗡响，研发压力大呀）等警示，就是告警。绝大部分公司，主要是通过文字发出系
-
编辑 删除
集群信息管理，架构设计中最容易遗漏的一环
准备系统性介绍“技术体系规划”了，这是第一篇。监控平台，服务治理，调用链跟踪，数据收集中心，自动化运维，自动化测试…很多要讲，却没想好从哪里入手。讲Z平台，可能需要提前介绍Y服务；讲Y服务，可能需要提前介绍X知识。思来想去，准备从技术体系里，最容易被遗漏，非常基础，却又非常重要的“集群信息管理”开始
-
编辑 删除
服务挂了，怎么自动恢复？
大家或许都碰到过这样的情况：tomcat挂了，站点应用访问不了service出core了，服务挂了架构设计上，避免单点，使用故障自动转移固然能够保证系统的高可用，是否还有其他的方案，让挂掉的服务自动启动呢，这里给大伙推荐一个常见的运维工具supervisor。画外音：supervisor是很常见的运
-
编辑 删除
为啥总在凌晨上线，如何无损发布
为什么很多公司升级系统，选择在晚上上线？答：美名其曰，晚上上线，对用户影响最小。为什么会对用户产生影响？答：系统升级往往需要重启，重启的过程中，正在访问的用户会访问失败。如果升级的是web-server：如上图，重启ip1上的tomcat时，tomcat上或许有1000个http请求正在处理，这些请
-
编辑 删除
rm -rf * 了咋办，跑路吗？
昨天有个工程师写了一个删除日志的bug：...rm-rf/home/work/logs/...还好是在测试环境执行的，否则估计要跑路了。画外音：一个“多了一个空格”的bug，看懂了么？曾经我也干过类似的傻事，写过这样删除日志的脚本：...cd${log_path}rm-rf*...进入到日志目录，然
-
编辑 删除
db如何快速回滚+恢复，DBA的神技能
技术人如果经常线上操作DB，河边走久了，难免出现纰漏：update错数据了delete错数据了drop错数据了咋办？找DBA恢复数据呗，即使恢复不了，锅总得有人背呀。画外音：把数据全删了，怎么办，怎么办？零，哪种方案不能实现数据恢复？从“从库”恢复数据。一般来说数据库集群是主从架构：如果人为执行了“
-
编辑 删除
朋友圈微博feed流，推拉实践
上一篇《feed流拉取，读扩散，究竟是啥？》关于feed流的拉取还是推送，只写了一半“拉取”，今天把另一半“推送”（写扩散）的坑填完。为了对比“拉”“推”两种方案，同时也为了避免大伙在两篇文章切换，故先简单赘述背景与“拉”（读扩散）方案。feed业务特点：有类似于“关注/粉丝”的好友关系，个人的主页
-
编辑 删除
feed流拉取，读扩散，究竟是啥？
任何脱离业务的架构设计都是耍流氓。哪些产品是feed流典型业务？答：微博，微信朋友圈，Pinterest是典型的feed流业务，系统中的每一条消息就是一个feed。这类业务的特点是：有好友关系，例如关注，粉丝我们的主页由别人发布的feed组成这类业务的典型动作是：关注，取关发布feed拉取自己的主页
-
编辑 删除
群消息，究竟存1份还是多份？
群消息，究竟存一份还是多份？上一篇文章《群消息已读回执，究竟是推还是拉？》说，“很容易想到，是存一份”，被网友们骂了。网友骂的对，任何技术方案，都不是天才般灵感乍现想到的，一定是一个演进迭代，逐步优化的过程。今天就聊一聊，群消息，为啥只需要存一份。群信息，用户信息，群成员关系都是基础数据：group
-
编辑 删除
群消息已读回执（这个diao），究竟是推还是拉？
每当发出一条微信消息，都希望对方尽快看到，并尽快回复，但始终不知道对方是否阅读。每当收到一条不能立马回复的微信消息，都默默返回，假装没看见。画外音：不想回复的人，唉，你只是个好人。微信用于个人社交，产品设计上，在线状态，强制已读回执都有可能暴露个人隐私，故微信并无相关功能。钉钉用于商务交流，其“强制
-
编辑 删除
网页端收消息，究竟是推还是拉？
任何脱离业务的架构设计都是耍流氓。网页端收消息，究竟是推还是拉？需求缘起对于在网页端登录的用户A，发送方，也就是消息的来源有几方面：系统发给A的“系统通知”，可能对实时性要求没这么高用户发给A的“聊天消息”，有对实时性要求比较高，越实时越好消息的处理方，也就是系统侧，一般来说：有服务对消息进行逻辑处
-
编辑 删除
状态同步，究竟是推还是拉？
任何脱离业务的架构设计都是耍流氓。状态同步，有好友状态的同步，有群友状态的同步，有的需要实时同步，有的能够容忍延时。结合具体场景来看下，状态同步，究竟是推还是拉。用户的在线状态，分为客户端状态(端)，服务端状态(云)两种形态。什么是服务端状态？服务端状态，主要分为在线online和离线offline
-
编辑 删除
系统通知，居然有人使用拉取？
任何脱离业务场景的架构设计都是耍流氓。广义系统通知，有1对1的通知，以及一对多的通知，有相对实时的业务通知，以及能够容忍一定延时的系统通知。结合具体的场景来看下，这样的一些系统通知，究竟是推还是拉？一、系统对1的通知典型业务，计数类通知：有10个美女添加了你为好友有8个好友私信了你很多业务经常有这类
-
编辑 删除
群聊比单聊，为什么复杂这么多？
群聊是多人社交的基本诉求，一个群友在群内发了一条消息，期望做到：(1)在线的群友能第一时间收到消息；(2)离线的群友能在登陆后收到消息；群消息的实时性、可达性、离线消息的复杂度，要远高于单对单消息。常见的群消息流程如何？群业务的核心数据结构有两个。群成员表：t_group_users(group_i
-
编辑 删除
消息顺序性为何这么难？
很多业务都需要考虑消息投递的顺序性：单聊消息投递，保证发送方发送顺序与接收方展现顺序一致群聊消息投递，保证所有接收方展现顺序一致充值支付消息，保证同一个用户发起的请求在服务端执行序列一致消息顺序性是分布式系统架构设计中非常难的问题，有什么常见优化实践呢？折衷一：以客户端或者服务端的时序为准不管什么情
-
编辑 删除
微信多点登录，消息漫游，假如让你来实现？
有朋友问：微信如何实现手机端、PC端同时登录，同时收消息？微信能不能实现，换一个手机，仍能拉取到历史消息？这是多点登录和消息漫游的问题。什么是多点登录？以微信为例，可以PC端，phone端同时登录，同时收发消息。画外音：需要注意的是，一个端只能登录一个实例，例如同一个QQ号，在pc1上登录，再到pc
-
编辑 删除
不在线，好友发给我的微信消息，会不会丢？
不管是MQ(MsgQueue)的消息投递，还是单人实时聊天的消息投递，都需要通过应用层的超时、重传、确认、去重来保证消息的可靠投递。但是，如果没有打开手机，没有登录微信，好友发给我的微信消息，有没有可能丢失呢？这是今天和大家分享的话题。画外音：初步一想，离线消息存库不就好了么？往后看，会比你想象的更
