SpringCloud2.0是基于SpringBoot2.0开发,jdk要求 1.8以上、是一套微服务解决方案。--并且通过RPC远程调用
项目包括:前台项目和后台项目。
服务:只包含业务逻辑层。
1.网站架构演变过程
单体架构:通常我们在软件设计当中,我们一般都会使用经典的三层模型:即表现层,业务逻辑层,数据访问层,然后打包在一台服务器上。
在一个小型应用的初始节点,访问量小,应用只需要一台服务器就能够部署所有的资源,例如将应用程序,数据库,文件资源等部署到同一台服务器上。最典型的就是LAMP系统。
存在不足:
1.业务越来越复杂,新人接手项目时,需要花费大量时间熟悉代码,进行业务的扩展。
2.随着用户越来越多,程序所受的高并发越来越高,单体应用的并发能力有限。
3.测试的难度越来越大。
耦合度极高,因为它是单个服务,某一个模块不可用时,可以导致其他模块也不可用,
例如当一个人注册失败时,也有可能影响到别人进行查询 。
单体架构使用服务器集群:
随着业务的发展,大多数公司会将对单体应用程序进行集群部署,并增加负载均衡服务器。另外还需要增加集群部署的缓存服务器和文件服务器,并对数据库的读写分离,以应对用户增加带来的高并发访问量。
存在不足:
1.系统仍然是单体应用,大量的业务必然拥有大量的代码,代码的可读性和可维护性依然很差。
2.面对海量用户,数据库将会成为瓶颈,解决方案为使用分布式数据库。
3.持续交付能力差。即业务多,代码复杂,新人加入项目开发需要长时间了解项目代码。
分布式架构:
分布式架构是基于传统架构演变过来的,将传统的项目以项目模块进行拆分成n多个子项目,
比如拆分成会员项目,订单项目,支付项目,优惠券项目。
如何进行通信:通过RPC进行远程调用,每个项目中都有自己的独立数据库,独立的redis缓存。
和传统架构项目来比,项目粒度分的更加细,慢慢开始适合于互联网公式开发,耦合度降低了。
maven聚合项目:不一定是 分式架构项目
因为我们在对项目进行打包的时候 ,如果项目是单个war/jar包,那这个maven聚合项目就不是 部分式架构项目
如果说我们将前台打包成一个war,后台打包成一个war。项目之间通过RPC进行远程通信,则该项目是分布式项目。
SOA架构:
指的是面向服务进行架构,俗称服务化,没有视图层。面向业务逻辑层,将共同的代码抽取出来,提供给其他接口进行调用,
服务与服务之间采用rpc远程调用技术。
比如我们有一个 会员业务:
controller service dao
架构图:
SOA缺点:
1.依赖于中心化服务发现机制
2.因为SOA架构采用SOAP协议(HTTP+XML),XML重量级数据传输格式,比较占用宽带,整个XML报文中有很大的数据冗余。
3.服务管理非常混乱,缺少服务管理和治理设置不完善。
微服务:从SOA架构演变过来的
Martin Fowler 提出:
简而言之,微服务就是将单一程序开发成一个微服务,每一个微服务运行在自己的进程中,并使用轻量级机制通信,通常是
Http Restful API 。这些服务围绕业务能力来划分构建的,并通过完全自动化部署机制来独立部署,这些服务可以使用不同的编程语言,以及不同的数据库存储技术,以保证最低限度的集中式管理。
1.微服务单元按照业务来划分
2.微服务通过HTTP协议来互相通信
服务与服务之间可以通过消息总线来通信,例如RabbitMQ, Kafaka等。通信的数据格式一般是JSON或者XML。
3.微服务的数据库独立。
按照业务划分服务,服务和服务之间没有耦合,就连数据库也是独立的。
4.微服务的自动化部署
在微服务架构当中,系统会被拆分为不同的服务单元,每一个微服务又是一个独立的应用程序,单体架构中的应用程序只需要部署一次,而微服务是有多少个微服务就要部署多少次。
但是如果按照单体架构的方式,部署的难度就会大大的提升,而且微服务的数量越来越多,需要更多稳定的部署机制,Docke容器技术以及自动化部署技术(Jenkins)的出现,自动化部署变得越来越简单。
5.服务集中化管理
服务数量越多,管理起来就越复杂,因此微服务必须使用集中化管理。
例如SpringCould采用Eureka来注册服务和发现服务。也就是注册中心
Zookeeper,Consul等都是非常优秀的服务集中化管理工具。
6.分布式技术
分布式系统是集群部署的,由很多的计算机相互协作共同完成,他能够处理海量用户请求,当分布式对外提供服务时,用户是毫不知情的,还以为是一台电脑在提供服务。
7.熔断机制
为了防止“雪崩效应”时间的发生,分布式采用了熔断机制。
微服务架构图: