多看多听多总结

其中log，flush，set_pattern，set_formatter为纯虚函数。formatter为虚类。

连接接口定义。

多组织架构 ---- 数据层面隔离多租户架构 ---- 资源层面隔离。

MermaidPlantUMLKaTex

结构use_type

fill:#333;stroke:1;fill:none;important;important;important;important;important;important;important;important;important;important;important;important;important;important;important;important;«abstract»TiXmlBase«abstract»TiXmlNodeTiXmlText。

设计模式总结

nginx基础架构

如何画好架构图学习笔记

Fundamentals of Software Architecture：An Engineering Approach学习笔记

Software Architecture: The Hard Parts Modern Trade-Off Analyses for Distributed Architectures学习笔记

限制算法

从零开始学架构学习笔记

桌面解决方案

架构师修炼之道学习笔记

IM核心概念用户：系统的使用者消息：是指用户之间的沟通内容。通常在IM系统中，消息会有以下几类：文本消息、表情消息、图片消息、视频消息、文件消息等等会话：通常指两个用户之间因聊天而建立起的关联群：通常指多个用户之间因聊天而建立起的关联终端：指用户使用IM系统的机器。通常有Android端、iOS端、Web端等等未读数：指用户还没读的消息数量用户状态：指用户当前是在线、离线还是挂起等状态关系链：是指用户与用户之间的关系，通常有单向的好友关系、双向的好友关系、关注...

一 背景订单状态流转是交易系统的最为核心的工作，订单系统往往都会存在状态多、链路长、逻辑复杂的特点，还存在多场景、多类型、多业务维度等业务特性。在保证订单状态流转稳定性的前提下、可扩展性和可维护性是我们需要重点关注和解决的问题。以高德打车业务的订单状态为例，订单状态就有乘客下单、司机接单、司机已到达乘车点、开始行程、行程结束、确认费用、支付成功、订单取消、订单关闭等；订单车型有专车、快车、出租车等几种车型，而专车又分舒适型、豪华型、商务型等；业务场景接送机、企业用车、城际拼车等等场景。当订单状态

一、前言很多程序员画架构图头疼，不知道画什么、怎么画！分享、评审、述职、答辩，只要你在程序员这个行业，就几乎离不开要画图。一提到画图很多人就想站会起来喊，”内卷“、”内卷啦“、”PPT工程师“，但程序代码本身就是一种数学逻辑的具体实现，如果没有一些图表配合文字的阐述，讲真很难让所有人都能在共同的共识下进行交流。这不像是文科，”八表流云澄夜色，九霄华月动春城“ 上来就能联想到它是在描述啥。但是偏理科代码逻辑或架构设计，只能把抽象的内容用图表的形式展现出来，让大家在同一的共识下共同协同工作。

1、学习资源https://raft.github.io/

1、角色Proposer(提议者）：提出提案(proposal)。Proposal信息包含提案编号(Proposal ID）和提议的值(Value)Acceptor(决策者)：参与决策，回应Proposers的提案。收到Proposal后可以接受提案，若Proposal获得多数Acceptors的接受，则称该Proposal被批准。Learner(最终决策学习者)：不参与决策，从Proposers/Acceptors学习最终达成一致的提案(Value)......

1、组件图

服务提供者框架是指：多个服务提供者实现一个服务，系统为客户提供多个实现，并把它们从多个实现中解耦出来。服务提供者的改变对它们的客户端是透明的，这样提供了更好的可扩展性。如JDBC,JMS等就是服务提供者框架。通常有四个组件Service Interface 服务接口，将服务通过抽象统一声明，供客户端调用，由各个服务提供者具体实现 Provider Registration API 服务提供者注册API，用于系统注册服务提供者，使得客户端可以访问它实现的服务 Sevcie Acc.

1、符号

2、单体架构2.1单体架构好处主要体现在早期应用开发简单 易于对应用程序进行大规模的更改 测试相对简单直观 部署简单明了 横向扩展不费吹灰之力2.2局限性过度的复杂性会吓退开发者 开发速度缓慢 从代码提交到实际部署的周期很长，而且容易出问题 难以扩展 交付可靠的单体应用是一项挑战 需要长期依赖某个可能已经过时的技术栈...

1、概述2、分层表现逻辑处理用户与软件间的交互。表现层的主要职责是向用户显示信息并把从用户那里获取的信息解释成领域层或数据源层上的各种动作。数据源逻辑主要关注与其他系统的交互，这些系统将代表应用完成相关的任务。可以是事务监控器、其他应用、消息系统等。最主要的数据源逻辑是数据库，主要责任是存储持久数据。领域逻辑也称为业务逻辑，是应用必须做的所有领域相关工作，包括根据输入数据或已有数据进行计算，对从表现层输入的数据进行验证，以及根据从表现层接收的命令来确定应该调度哪些数据源逻辑...

1、基本重构1.1 提炼函数(Extract Function)将意图和实现分开，如果需要花时间浏览一段代码才能弄清它到底在干什么，那么就应该将其提炼到一个函数中，并根据它所做的事为其命名。

1、设计原则1.1 SRP 单一职责原则一个软件系统的最佳结构高度依赖于开发这个系统的组织的内部结构。任何一个软件模块都应该只对某一类行为者负责。单一职责原则主要讨论的是函数和类之间的关系，但是它在两个讨论层面上会以不同的形式出现，在组件层面，称为共同闭包原则，在软件架构层面，则是用于奠定架构边界的变更轴心。1.2 开闭原则一个好的软件架构师会努力将旧代码的修改需求量降至最小，甚至为0。如何实现这一点？先将满足不同需求的代码分组(SRP)，然后再来调整这些分级之间的依赖关系(DIP)

分库分表适用场景分库分表用于应对当前互联网常见的两个场景——大数据量和高并发。通常分为垂直拆分和水平拆分两种。垂直拆分是根据业务将一个库（表）拆分为多个库（表）。如：将经常和不常访问的字段拆分至不同的库或表中。由于与业务关系密切，目前的分库分表产品均使用水平拆分方式。水平拆分则是根据分片算法将一个库（表）拆分为多个库（表）。如：按照ID的最后一位以3取余，尾数是1的放入第1

以下为主题内容： 大家来京东打开商品页一般会看到如通用版、闪购、全球购等不同的页面风格，这里面会牵扯到各种各样垂直化的模板页面渲染。以前的解决方案是做静态化，但是静态化一个很大的问题就是页面改版时需要重新全量生成新的静态页。我们有几亿个商品，对于这么多商品，你如果生成页面的话需要跑很多天，而且还无法应对一些突发情况。 比如新的《广告法》，需要对一些数据进行清洗，

转自http://blog.jobbole.com/89140/前阵子从支付宝转账1万块钱到余额宝，这是日常生活的一件普通小事，但作为互联网研发人员的职业病，我就思考支付宝扣除1万之后，如果系统挂掉怎么办，这时余额宝账户并没有增加1万，数据就会出现不一致状况了。上述场景在各个类型的系统中都能找到相似影子，比如在电商系统中，当有用户下单后，除了在订单表插入一条记录外，对应商品表的

B 站直播弹幕服务架构（下面简称 GOIM ）的出现就是为了解决这一系列的需求。下面将对此进行详细的介绍。B 站直播弹幕服务架构 GOIM 的出现图  1直播聊天系统本质上也是一种推送系统，所谓推送系统就是，当你发送一条消息时，它可以将这个消息推送给所有人。对于直播弹幕来说，用户在不断地发送消息，不断地进行广播，当一个房间里面有 10 万人时，一个消息就要发出

在互联网应用领域，服务的动态性需求十分常见，这就对服务的自动发现和可动态扩展提出了很高的要求。Docker 的出现，以及微服务架构的兴起，让众多开源项目开始关注在松耦合的架构前提下，如何基于 Docker 实现一套真正可动态扩展的服务架构。基本需求基本的需求包括：服务启动后要能自动被发现(vs 传统需要手动进行注册);负载要能动态在可用的服务实例上进

概述截止到2015年7月，微信每月活跃用户约5.49亿，朋友圈每天的发表量（包括赞和评论）超过10亿，浏览量超过100亿。得益于4G网络的发展，以上数据仍有很快的增长，而且相对于PC互联网时代，移动互联网时代的峰值要来得更加凶猛。比如，2015年元月的流量到了平时的2倍，而峰值则达到了平时峰值的2倍，相当于平时正常流量的5倍，这对整个系统的考验是很残酷的。本次分享将简单介绍微信后台团队的开

快的打车从2013年年底到2014年下半年，系统访问量迅速膨胀，很多复杂的问题要在短时间内解决，且不能影响线上业务，这是比较大的挑战，本文将会阐述快的打车架构演变过程遇到的一些有代表性的问题和解决方案。LBS的瓶颈和方案先看看基本的系统模型，如图1所示。图1 系统模型示意图司机每隔几秒钟上报一次经纬度，存储在MongoDB里；乘客发单时，通过MongoDB圈选出

转自http://timyang.net/Pinterest首页的Feed消息流，最早是按照用户的关注对象的Pin（Pin类似微博）聚合后按时间进行排序（自然序，类似朋友圈），后来版本的feed系统放弃了自然序，而是根据一定规则及算法来设计，内部称之为Smart feed，其算法及架构根据其公开资料整理如下，值得业界做信息流产品的技术架构师参考。Pinterest每个用

宅米是一家专注校园电子商务的互联网企业，目前主营校园超市O2O。公司成立于2014年11月，仅仅一年多的时间，公司即经过4轮融资，覆盖近200座城市，1000多所大中专院校，10000多栋宿舍楼，日均订单20万，峰值订单50万。 像所有高速发展的初创互联网企业一样，宅米的成长是一部野蛮成长的历史。公司成立之初，只有三个工程师，是创始人CEO孙高峰在上海交通大学计算机学院和软件学院挨个宿舍敲门敲

挑战搜狗商业平台为打造搜狗一站式营销服务平台提供基础架构支撑，支持跨平台的广告主及代理商的接入、广告投放、效果评估、策略优化以及资金管理等。近年来搜狗业务飞速发展，在线广告物料实现了千万级到10亿+的增长，天级报文量完成了百万级到亿级的跨越，而一年一度的6.18、11.11互联网狂欢也更是对搜狗商业平台的基础架构提出了严峻的考验。从技术层面，搜狗商业平台涵盖了前端/后端框架、大数据

一、监控系统架构经历了许多公司，监控系统大概都是从无到有，该经历的也都经历了。所谓监控系统，大概的架构如下：◆在服务器布置一个Agent，它负责采集数据； ◆由网上转发到一个分布式管道再转接，就像搭积木一样； ◆进行汇总；之后把监控数据分两个部分●一是数据库存储，主要做监控数据展示和后续排查问题。●二是制定很多的监控的报警项。做一些简单的，像CPU超

链接：http://blog.jobbole.com/94962/提升 Web 应用的性能变得越来越重要。线上经济活动的份额持续增长，当前发达世界中 5 % 的经济发生在互联网上（查看下面资源的统计信息）。 我们现在所处的时代要求一直在线和互联互通，这意味着用户对性能有更高的期望。如果网站响应不及时，或者应用有明显的延迟，用户很快就会跑到竞争者那边去。例如，Amazon 十年前做的

编者按】 本文来自拥有十年IT从业经验、擅长网站架构设计、Web前端技术以及Java企业级开发的夏俊，此文也是《关于大型网站技术演进的思考》系列文章的最新出炉内容，首发于优快云，各位技术人员不容错过。以下为正文： 一、 引子《关于大型网站技术演进的思考》已经连载完了两个系列，它们分别是《存储的瓶颈》和《网站静态化的处理》，这两个系列对应到网站里的组件就是存储端和浏览器端，网站除了