浅谈分布式架构演进
前言
现在越来越多的互联网公司还是将自己公司的项目进行服务化，这确实是今后项目开发的一个趋势，从历史的角度来分析一下就比较明了了。
我们拿一个电商系统来说：
单系统
对于一个刚起步的创业公司项目肯定是追求越快完成功能越好，并且用户量也不大。
这时候所有的业务逻辑都是在一个项目中就可以满足。
垂直拆分-多应用
当业务量和用户量发展到一定地步的时候，这时一般会将应用同时部署到几台服务器上，在用户访问的时候使用Nginx进行反向代理和简单的负载均衡。
SOA服务化
当整个系统以及发展的足够大的时候，比如一个电商系统中存在有：1
2
3
4
5
6
7
8
9用户系统
订单系统
支付系统
物流系统
等等系统
如果每次修改了其中一个系统就要重新发布上线的话那么耦合就太严重了。
所以需要将整个项目拆分成若干个独立的应用，可以进行独立的开发上线实现快速迭代。
来源：http://www.jianshu.com/p/db67973cae79
聊天室
手机应用是以聊天室为基础的，我们需要收集用户的操作行为，然后计算聊天室中在线人数，并实时在手机应用端显示人数，整个系统的架构如图所示：
上图中，主要包括了两大主要流程：日志收集并实时处理流程、调用读取实时计算结果流程，我们使用基于Dubbo框架开发的服务来提供实时计算结果读取聊天人数的功能。上图中，实际上业务接口服务器集群也可以基于Dubbo框架构建服务，就看我们想要构建什么样的系统来满足我们的需要。
如果不使用注册中心，服务消费方也能够直接调用服务提供方发布的服务，这样需要服务提供方将服务地址暴露给服务消费方，而且也无法使用监控中心的功能，这种方式成为直连。
如果我们使用注册中心，服务提供方将服务发布到注册中心，而服务消费方可以通过注册中心订阅服务，接收服务提供方服务变更通知，这种方式可以隐藏服务提供方的细节，包括服务器地址等敏感信息，而服务消费方只能通过注册中心来获取到已注册的提供方服务，而不能直接跨过注册中心与服务提供方直接连接。这种方式的好处是还可以使用监控中心服务，能够对服务的调用情况进行监控分析，还能使用Dubbo服务管理中心，方便管理服务，我们在这里使用的是这种方式，也推荐使用这种方式。使用注册中心的Dubbo分布式服务相关组件结构，如下图所示：
