在同一台机器上部署多个服务，上游服务只请求本机的下游服务，服务之间使用 http 协议传输 protobuf 数据，每个机器都是一个完备的投放系统。

这个架构有很多的优点：结构清晰，运维简单，网络延迟最小化等。

当然也有一些缺点，同一台机器上可部署的服务数量是有限的，因而会限制架构的增长，多个模块混合部署不利于整体的性能优化，一个服务的异常会影响整个机器的服务质量；这个架构在微观上满足了单一服务的原则，但在宏观上还不是真正的微服务化，为了解决上面的一些问题，按照自然的演进我们必然走上微服务化这条路；我们从 16 年中开始进行微服务化的实践。

微服务化过程中我们也遇到了很多问题，分享一下我们的解决方法及效果：

1. 技术选型问题

RPC 选型，必须满足的条件是要支持 C++、protobuf 协议和异步编程模型。最初的可选项有 sofa-pbrpc、pbrpc 和 grpc，这三者中我们选中了 grpc，主要看中了它通用（多语言、多平台和支持代理）、流控、取消与超时等特性；在我们选定 grpc 之后不久百度开源了它的高性能 rpc 框架 brpc，相比之下 brpc 更具有优势：健全的文档，高性能，内置检测服务等非常多的特性；为此我们果断地抛弃了 grpc 和已经在上面投入的一些开发成本，快速地展开了 brpc 相关的基础功能开发和各服务的改造。

名字服务选型，排除了 zookeeper，etcd 等，最终选定的是 consul+consul template 这个组合，它很完美地支持了我们的业务需求；除服务注册与发现外，还有健康检查，服务列表本地备份，支持权重设置等功能，这些功能可以有效地减少团队成员的运维工作量，增强系统的可用性，成为服务的标准配置。

2. 运维成本增加

这是微服务化带来的问题之一，微服务化要做服务拆分，服务节点的类型和数量会增多，同时还要额外运维一些基础服务（譬如，名字服务的 Agency）。考虑到大部分运维工作都是同一个任务在多个机器上重复执行，这样的问题最适合交由机器来完成，所以我们的解决方案就是自动化运维。我们基于 Ansible 自研了一个可视化的自动运维系统。其实研发这个系统最初目的并不是为了支持微服务化，而是为了消除人工运维事故，因为人的状态是不稳定的（有时甚至是不靠谱的），所以希望由机器来替代人来完成重复的标准动作；后来随着微服务化的推进，这个系统很自然地就接管了相关的运维工作。现在这个系统完成了整个团队 90% 以上的运维工作量。