系统结构的发展以及为什么要使用分布式系统
本人认识分布式系统是从微服务开始接触的，所有分布式的知识都是以微服务视角来描述和理解。其中涉及到的技术主要以spring cloud为主。能力有限，难免会有疏漏。欢迎各位指正和交流。
A. 传统的单体服务
在传统互联网项目中，我们往往以一个项目的形式进行开发。在项目中通常将需求分割成不同的三个部分。数据库，服务端处理，前端展示。在业务发展的初期，数据量小，功能单一。所以开发、测试、部署都很方便。但是随着业务的拓展，用户的增加。系统为了适应市场的需求改变会新增很多不同的功能。导致了单体应用的体积越来越臃肿，占用的资源越来越多，对服务器的性能要求越来越高，服务器因此不堪重负，最后宕机。但是，这还不是最后的结果。越来越臃肿的项目导致了代码的累积堆叠越来越复杂，后期的维护变得更加困难。反复的修改打补丁导致系统的稳定性严重受损。于是，服务化的架构应运而生
B.服务化的架构
在传统的互联网单体服务发展到瓶颈时，出现了服务化的架构。服务化架构已经很类似于微服务架构的理念了。服务化架构的理念就是将一个大的单体应用拆分成多个小的单体应用，每个应用之间通过暴露的接口来沟通。然后将接口组合成前端对应的数据展示。但是每个应用之间没有同意管理，应用之间无法确认状态，此时的系统结构是及其不稳定的。无法水平扩展提高吞吐量，很难应对高并发场景。
C.服务总线的架构
在服务化架构出现之后，其对应的问题也马上暴露出来。于是就有了消息总线的架构模式。针对于所有的单体服务都有一个消息总线来管理。每个服务都要链接到消息总线上，由消息总线来维护服务的是否可用。但是，这总模式依然存在水平扩展以及消息总线的性能瓶颈问题。
D.微服务的架构
微服务的架构理念集合了服务化以及消息总线。将每一个单例服务都切割成小的服务，每个服务都有对外暴露的几口，并注册到服务管理中心中。服务管理中心依然可以相互注册，是整个服务成一个网状接口，一次来保证高可用性。没有一个微服务都可以建成集群注册在服务治理中心中。
分布式系统解决了互联网时代的数据爆发以及高并发的吞吐问题。为后续的功能扩展以及性能提升提供了强有力的支持。
注：微服务是一种架构理念，将一个传统的单体服务分割成多个不同的服务，每个服务间不依赖，彼此之间以REST格式的接口进行通信。