作者：不洗碗工作室 - Marklux

出处：Dubbo入门(1) - 基础概念

版权归作者所有，转载请注明出处

前言

本文主要是针对以下几个问题的笔记：

服务端的架构是如何一步步演变的？
什么是分布式服务框架？它用于解决什么问题？
什么是微服务架构？主要应用于何种场景？

参考自：聊聊dubbo及其微服务那点事

服务架构的演变

随着互联网的逐渐发展和壮大，服务端的架构也在不断变得更庞大、更复杂。

大概的演变过程分为以下几个阶段：

单一应用架构

服务端解决所有问题，从数据储存到MVC。应用规模较小的时候可以采用这种架构，绝大多数学生时代的课设或是小型web项目都是这种结构。

一台服务器，一个开发框架，一个数据库便构成了一个完整的应用。

这一阶段主要的性能瓶颈是ORM，因为整体应用通常是对数据库CURD操作的一个封装，所以性能最终取决于数据库以及应用框架与数据库之间的连接部分。
垂直应用架构

当应用规模增大时，单一服务支撑整个应用就显得有些力不从心了，此时需要对服务进行拆解。

最常见的拆解是前后端分离，此时服务端专注于提供接口，可以将服务进一步拆解成几个不相关的部分独立垂直部署，而前端提供一个统一的入口。

这一阶段的主要性能瓶颈是MVC，换句话说，页面的组织和开发将会是整个项目中最耗时的一部分（在没有复杂业务的前提下）。
分布式服务架构

当垂直应用越来越多时，就不可避免的产生交叉，此时的做法是将核心业务抽离出来，作为独立的服务中心部署。

而一个应用依赖的服务数量可能已经是一个非常庞大的数字，必须要对所有这些服务进行必要的监控、调整以及整合。

这一阶段主要的性能瓶颈便是分布式服务框架(RPC)。
流动计算架构

服务越来越多，容量的评估，小服务资源的浪费等问题便愈发严重，此时需增加一个调度中心基于访问压力实时管理集群容量，提高集群利用率。

这一阶段的主要性能瓶颈是资源调度和治理中心(SOA)。

上面的演变流程可以参考下图：

分布式服务框架的关注点

从个人理解的角度出发，针对大型应用编程的时候，设计的思路不再是面向服务器的一条龙式编程，而是面向服务的编程，这是一个重要的思维模式的转换。

开发人员的关注点也随之发生变化，在分布式服务框架中，我们需要关注的问题有以下几个：

总结

我们把分布式架构下的需要解决的问题梳理整理一下，就可以明白一个分布式服务框架需要提供哪些功能：

API Gateway（服务入口）
服务间调用（RPC,RESTful）
服务发现（Zookeeper）
服务容错（Hytrix）
服务部署和治理（Docker,服务网格）
数据调用（数据中心、最终一致性）

用下面这个图可以更直观的了解整体的结构（原图是描述微服务的，但对分布式服务同样有效）

当然要写好一套分布式的服务，不只是使用一个分布式框架就可以解决的，还需要对服务进行合理的拆分，编写出适合分布式结构的代码，以及后期的治理、维护。

另外微服务、分布式服务等概念带来的意义在于给服务端开发者带来对技术架构的一个全新意识，而不是抽象的概念、定式的模板。具体落地使用什么样的解决方案，还是要针对业务场景来进行调整的。