1.1 单体架构(单个tomcat)
单体架构应该是我们最先接触到的架构实现了,在单体架构中使用经典的三层模型,即表现层,业务逻辑层和数据访问层。
单体架构只适合在应用初期,且访问量比较少的情况下使用,优点是性价比很高,开发速度快,成本低,但缺点也很明显,这时扩展的首先就是考虑服务器的集群处理。
1.2 集群(多个tomcat)
针对单个服务器在访问量越来越大的情况越来越吃力的情况,我们可以考虑服务器的集群话处理。
集群的部署大大提高了服务的处理能力,同时利用Nginx提供的负载均衡机制,来分发请求,使用户的体验没有改变。
1.3 垂直化(业务拆分成多个服务)
上面的集群部署是可以解决一部分的服务器压力,但是随着用户访问量的增多,集群节点增加到一定阶段的时候,其实作用就已经不是太大了,因为将所有的业务都集中在一起,造成耦合度很高,这时我们可以考虑业务的拆分。来提高系统的性能。比如将原来在一个系统里面的业务拆分为用户系统,订单系统和商品系统。也就是我们讲的垂直化拆分如下:
服务垂直化拆分后是可以大大的提高整体的服务处理能力,但是也会出现很多的冗余的代码,比如用户系统要操作订单库,要操作商品库,订单系统也有可能要操作用户库和商品库等。
1.4 服务化(SOA)
针对垂直化拆分出现的问题,这时就出现了我们经常听到的SOA(面向服务的架构)。什么是SOA呢?在《微服务设计》中有这么一段描述:
SOA是一种设计方法,其中包括多个服务,而服务之间通过配合最终会提供一系列功能,一个服务通常以独立的形式存在于操作系统进程中,服务之间通过网络调用,而非采用进程内调用的方式进行通信。
业务重用,共享服务,简单理解,抽出ESB。
1.5 微服务化
在SOA的基础上继续演进就是我们讲的微服务。SOA的服务更细粒度的拆分后就是微服务。根据时间递进,对基础运维的要求能力会越来越高,虚拟化,容器话等。
微服务和SOA的区别:
1.思想:微服务的目的是解耦而SOA的目的是实现数据的互通和共享性。
2.协议:微服务会使用一些轻量级的通信协议(Restful API)。
3.基础设施要求:微服务更加强调开发运维的持续交付。