商城系统架构的演变

单体架构

单体架构应该是我们最先接触到的架构实现了，在单体架构中使用经典的三层模型，即表现层，业务逻辑层和数据访问层。

单体架构只适合在应用初期，且访问量比较下的情况下使用，优点是性价比很高，开发速度快，成本低，但缺点也很明显，这时扩展的首先就是考虑服务器的集群处理，就是性能扩展比较难，还有协同开发问题、不利于升级维护

集群

针对单个服务器在访问量越来越大的情况越来越吃力的情况，我们可以考虑服务器的集群话处理。

集群的部署大大提高了服务的处理能力，同时利用Nginx提供的负载均衡机制，来分发请求，使用户的体验没有改变。

垂直化

上面的集群部署是可以解决一部分的服务器压力，但是随着用户访问量的增多，集群节点增加到一定阶段的时候，其实作用就已经不是太大了，因为将所有的业务都集中在一起，造成耦合度很高，这时我们可以考虑业务的拆分。来提高系统的性能。比如将原来在一个系统里面的业务拆分为用户系统，订单系统和商品系统。也就是我们讲的垂直化拆分如下：

服务垂直化拆分后是可以大大的提高整体的服务处理能力，但是也会出现很多的冗余的代码，公用模块无法重复利用，开发性的浪费，比如用户系统要操作订单库，要操作商品库，订单系统也有可能要操作用户库和商品库等。

分布式应用架构

将各个应用通过分层独立出来，可以利用rpc实现web与service、service与service的互相调用，提高了代码的复用性。
缺点： 每个调用的模块要存储一份完整的被调用模块的位置和状态，一旦位置和状态发生变化，就要更新所有涉及的配置。

针对垂直化拆分出现的问题，这时就出现了我们经常听到的SOA(面向服务的架构).什么是SOA呢？在《微服务设计》中有这么一段描述

SOA是一种设计方法，其中包括多个服务，而服务之间通过配合最终会提供一系列功能，一个服务通常以独立的形式存在于操作系统进程中，服务之间通过网络调用，而非采用进程内调用的方式进行通信。

业务重用，共享服务，

微服务化

在SOA的基础上继续演进就是我们讲的微服务。SOA的服务更细粒度的拆分后就是微服务。根据时间递进。

对基础运维的要求能力会越来越高，虚拟化，容器话等。

微服务和SOA的区别：

1.思想上：微服务的目的是解耦而SOA的目的是实现数据的互通和共享性。

2.协议：微服务会使用一些轻量级的通信协议(Restful API)

3.基础设施要求，微服务更加强调开发运维的持续交付。

转载自：
https://dpb-bobokaoya-sm.blog.csdn.net/article/details/125930698

当时，英国的王位上坐的是一位大下巴的国王和一位容貌平常的王后；法国的王位上坐的是一位大下巴的国王和一位容貌姣好的王后。在这两个国家那些坐食俸禄的权贵们心中，有一点比水晶还要明澈，那就是大局已定，江山永固了。

双城记
狄更斯