一年半以前，我在一家创业公司从事服务器端开发工作，虽然当时公司已经拿到了6000w的A轮融资，并且App已经有超过百万的日活，开发团队已经有10几个人。但是看一眼服务器的代码，却感觉和笔者本科时候做的“学生管理”系统没什么两样。所有的服务器代码，都在一个JavaWeb工程里，然后被打包成War，使用Tomcat部署。为了应对增长的活跃用户，使用Haproxy做了负载均衡，同样的war包会在5-10台左右的高性能机器上部署，感觉应对当时的日活并没有太大问题。

当时公司的业务分大概几个模块：
1. 一个是广告分发业务，用户会定期收到推过来的广告，当然有一些复杂的机制来决定用户看到什么广告。
2. 积分系统，用户通过浏览广告，可以赚取积分。
3. 商场系统，用户可以用积分换取商场里的物品。

虽然业务听起来不是很多，但是因为业务模式比较复杂，代码也是极为庞大，而所有的一切都在一个工程中。虽然代码也是按照Controller， Service，DAO这样横向拆分，也按照Package做了很好的分割。但是依然维护和继续开发这一坨东西，让我日渐有一种忍无可忍的感觉。

1. 从开发角度说，面对这么一坨庞大的代码，维护成本和新人学习成本都是特别高的。
2. 代码保护性很差，如果公司来了一个实习生，我不想让他看到所有代码，但是又想让他做一些相关的功能，都几乎不太可能。
3. 代码构建的时间越来越长，每一个小小的改动，都会触发所有代码的构建，程序员如此贵的今天，如果让老板知道，肯定眼泪掉下来。
4. 发布成本也很高，先不说庞大的war包重启需要更长时间，每次一个小改动就要重新部署所有功能，也是非常头疼的事情。因为有些核心功能，需要全天服务用户，所以白天几乎不可能重启服务。而发布一个无关紧要的功能，也要守候到凌晨，真是觉得这个世界充满恶意。
5. 即使可以通过 LBS 增强服务器响应，但是确完全不能根据不同的业务做扩容，每次增加机器都要考虑整个War的感受，额外提高的设备成本。

经过大量调查和探索，我们走上了微服务架构这条路。

简而言之，微服务架构就是按照业务，将服务拆分到不同的程序（进程），单独部署，发布。
可以看图，曾经的架构-单块架构，可以这样理解：

所有的程序都是在一个war包中，是一个单独的进程。
而微服务则可以表现为：

其中每个Service可以理解成针对不同的业务做的拆分，每个 Service 单独部署，运行为独立的程序。

在我们当时的系统中，就把整个系统拆分成，广告服务，商城服务，积分服务，账号服务。 而和App做交互的部分－对应图中的WebUI，这个工程是一个 Java Web 工程，打包成 war 用来处理 App 请求。
实际中，我们的部署要远远比图中所画复杂，部署服务的机器超过6台，每台服务器运行2-3个服务，而这些服务通过注册中心注册自己的存在，服务消费者（consumer, 图中的web ui）可以发现并调用这些服务。当某些服务，访问日渐变多（例如商城最近生意越来越好），我们可以直接增加机器，多部署一些商城服务，就可以直接提高系统的处理能力。

那标题里的Dubbo到底在哪，根据上面笔者的描述，你会发现，部署成微服务需要额外的通信手段，连接服务提供者，和服务消费者。在单块架构中，服务的调用是通过程序调用。而在微服务架构中，调用是通过Http请求的方式来执行程序调用。那么问题来了，对于服务消费者，如何发现服务的存在，如何调用服务，调用服务的协议如何规定，没有得到返回如何重试。 这就是Dubbo所解决的问题，也是她可以作为框架的原因。

当这套方案Work以后，我们觉得很兴奋，架构的升级后，带来的效果还是立竿见影的。当然也在实践中遇到额外问题，例如mybatis本地缓存在不同服务的不一致问题，处理数据一致性需要的额外代价等问题，后面我会一一探讨采用微服务遇到的问题和我们的解决方案。

长篇大论的介绍微服务的优势，并不是本系列文章的目的，因为这样的文章很多。笔者更希望提供一些可实施的干货，无论从理论基础，还是从实践部署中，远离群众的空谈，我觉得不适合我写系列文章的目的。在这系列的文章里，我会呈现下面的内容：

1. 首先会给出一份真实的代码，搭建出一份基于本地调用的Dubbo微服务框架。
2. 使用Zookeeper，使程序支持注册中心，支持热拓展。搭建Dubbo monitor，让你更直观的理解所有服务，消费者的关系。
你会发现用了这套方案，你可以瞬间提高你的服务器对并发对处理能力。
3. 从整体架构上，理解Dobbo。
4. 阅读代码，研究Dubbo 服务提供者（Provider）的实现原理
5. 阅读代码，研究Dubbo 服务消费者（Consumer）的实现原理

当然，这是规划的最核心内容，也可能呈现更多内容！
传送门：http://sunrising.me/?p=111