天地未开，万物归一

• 那时的软件及其简单，由于业务并不复杂，且参与人员较少，一般一个系统就能包含所有功能。

  
  image.png

天地初开，万物混沌

• 为了能够实现资源共享不是局限于在一台/组计算机上，出现了client/server模式，我们一般叫做c/s，b/s结构。cs就是常见的需要安装客户端的软件（比如网游客户端，手机app等），bs也就是目前我们最常用的通过浏览器访问服务端模式。随着前后端的分离，技术语言也发生着变化，异构的出现使得开发人员向专业化发展。

image.png

日月星辰

• 随着业务越来越复杂，人员增多更迭，单一系统的维护成本越来越高，往往一小段底层代码变动导致上层大片业务需要回归甚至变更，这就导致很多开发人员不愿意去改原代码，重写一个自己需要的匆匆了事，最终使得代码腐化难以继续。在这些复杂业务的驱动下，出现了服务治理工具，比如最流行的dubbo。每个服务负责单个或几块业务，服务之间相互调用依赖。

  
  image.png

山川河岳

• 上图可以看到，随着业务更加复杂，系统间的调用也变得越加复杂。然后就变成了(我画的都看不懂了，你还能看懂？)

  
  image.png

• 即便有监控服务，也很难有人能讲清楚中间的调用链路。更要命的是如果一个基础服务依赖一个上层业务接口，一旦上层业务出现问题，会直接传导到基础服务，继而产生雪崩效应传导到整个平台。这个时候就需要消息中间件的引入，例如最常用的rabbitMQ,kafka等，当然消息中间件并不能解决调用链路混乱的问题，但能解决依赖，将服务与服务间解耦。

  
  image.png

江河湖泊

• 说完服务治理，再来说说缓存，缓存也是架构中必不可少的一环。一般缓存的作用是用来共享数据，或是用来作为数据库前的一层屏障，防止数据库击穿。就好像江河湖泊一样，取之用之而不必关心水是从哪儿来的。

  
  image.png

风雨雪电

• 最后说说配置中心。系统多了后，每个系统都有必要的配置需要维护，有静态的有动态的。有的开发人员喜欢维护在数据库，有的喜欢维护在文件不一而足。每次有配置变更的时候，就像一个广播请求，一下子冲击到所有业务组，怨声载道。配置中心就是提供了这样一种统一的处理方式。