美国计算机科学家，LaTex的作者Leslie Lamport说：“分布式系统就是这样一个系统，系统中一个你甚至都不知道的计算机出了故障，却可能导致你自己的计算机不可用. ”一语道破了开发分布式系统的玄机，那就是它的复杂与不可控. 所以Martin Fowler强调：分布式调用的第一原则就是不要分布式.

随着社会的发展，经济的飞跃，传统的单系统模式（webApp+DB）已经很难满足业务场景的需要. 企业系统开始不断演化成多个子系统并存协作的局面. 大大降低了系统间的耦合性，更重要的便于子系统的扩展、升级、维护等. 谈到系统间的协作，目前常用两种方式：. 通过客户端发起的get、post请求，服务端接收request请求，处理请求，得到响应内容，通过网络传送到客户端，由浏览器解析出一个可视化的页面.

最近一两年，大部分系统的数据流由基于日志的离线处理方式转变成实时的流式处理方式，并逐渐形成几种通用的使用方式，以下介绍微博的消息队列体系. 当前的主要消息队列分成如图3部分. 1、feed信息流主流程处理，图中中间的流程，通过相关MQ worker将数据写入cache、Redis及MySQL，以便用户浏览信息流.

Kafka是分布式发布-订阅消息系统. 它最初由LinkedIn公司开发，之后成为Apache项目的一部分. Kafka是一个分布式的，可划分的，冗余备份的持久性的日志服务. 在大数据系统中，常常会碰到一个问题，整个大数据是由各个子系统组成，数据需要在各个子系统中高性能，低延迟的不停流转. 传统的企业消息系统并不是非常适合大规模的数据处理.

Kafka[1]是linkedin用于日志处理的分布式消息队列，linkedin的日志数据容量大，但对可靠性要求不高，其日志数据主要包括用户行为（登录、浏览、点击、分享、喜欢）以及系统运行日志（CPU、内存、磁盘、网络、系统及进程状态）. 当前很多的消息队列服务提供可靠交付保证，并默认是即时消费（不适合离线）.

互联网的网站和大部分企业管理软件一样都是使用B/S架构模型，但是大型的公共网站B/S架构会更加复杂，对架构人员的要求更高，今天我想在自己博客里聊聊我设计的网站的B/S技术架构. 不管是B/S架构的企业管理系统还是网站技术架构可以抽象为如下简图：. 在传统B/S架构的企业管理系统里，技术架构往往就是一个工程项目，各个逻辑分层都是该工程的业务逻辑模块.

FastDFS分布式文件系统架构.            FastDFS是一个开源的分布式文件系统，她对文件进行管理，功能包括：文件存储、文件同步、文件访问（文件上传、文件下载）等，解决了大容量存储和负载均衡的问题. 特别适合以文件为载体的在线服务，如相册网站、视频网站等等. 二、 FastDFS系统架构.

今天小蕉跟大伙一起聊聊分布式系统的架构的套路. 在开始说套路之前，大家先思考一个问题，为什么要进行分布式架构. 大多数的开发者大多数的系统可能从来没接触过分布式系统，也根本没必要进行分布式系统架构，为什么. 因为在访问量或者QPS没有达到单台机器的性能瓶颈的时候，根本没必要进行分布式架构. 那如果业务量上来了，一般会怎么解决呢.

这周一下了个决定"裸辞"，逼自己一把. 当你在一个复杂的环境下，对所负责的项目失去激情时、不开心时你会选择怎样. 已经进入到分布式架构系列的尾声了，倒数第三篇文章. Paxos、Raft、以及变种/类似的协议都是用于在分布式里面解决选举的问题. 2pc、3pc、Waro是保证数据的强一致性，它们之间的强一致性在层次上是不同的概念、解决的问题不同，需要注意区分.

    最近一直比较忙，前面设计的架构完成了基本的实现，最近工作重心发生了点转变，偷闲来继续前面的话题；.     这一篇博客准备聊聊消息系统，消息中间件对目前大中型互联网来说是非常重要的，在业务数据流动中仅次于RPC服务调用，担负着越来越复杂的网站业务从主流程上解耦的重要责任；.     从目前互联网对消息中间件的需求来看应该分为两种类型，一种是和钱相关的需求，一种是和钱无关的需求；和钱相关的需求消息的可靠性是放在第一位的，和钱无关的需求是速度放在第一位的，但这两种需求又是矛盾的，很难设计出一种既可靠又高效的系统，除非将两套方案捏合成一个系统，通过配置来选择不同方案，但从实现上说还是两种实现.