在了解SpringCloud之前,我们先来大致了解下微服务这个概念吧。
传统单体架构
单体架构在小微企业比较常见,典型代表就是一个应用、一个数据库、一个web容器就可以跑起来。
可以从上图看出,单体架构基本上就是如上所说的:一个应用,一个数据库,一个web容器,里面集成了所有的功能。这在小型项目里面时比较好维护的,毕竟功能不多,也不复杂,但扩展性和可靠性比较差,因为所有功能集成在一个服务或者一个war包中,修改某个功能时,需要所有服务重新打包。可能前期开发比较快,后期随着功能的增长,交互的周期会越变越长的。
服务化架构
服务化架构,也可以称之为SOA架构。
SOA代表面向服务的架构,将应用程序根据不同的职责划分为不同的模块,不同的模块直接通过特定的协议和接口进行交互。这样使整个系统切分成很多单个组件服务来完成请求,当流量过大时通过水平扩展相应的组件来支撑,所有的组件通过交互来满足整体的业务需求。
SOA服务化的优点是,它可以根据需求通过网络对松散耦合的粗粒度应用组件进行分布式部署、组合和使用。服务层是SOA的基础,可以直接被应用调用,从而有效控制系统中与软件代理交互的人为依赖性。
服务化架构是一套松耦合的架构,服务的拆分原则是服务内部高内聚,服务之间低耦合。
一般上我们使用dubbo来进行服务的治理功能,没有使用SpringCloud之前,基本上都是使用dubbo来拆分服务,进行服务间的调用。
看下服务化架构的架构图:
可以发现从单体架构到服务化架构,应用数量都在不断的增加,慢慢的下沉的就成了基础组建,上浮的就成为业务系统。从上述也可以看出架构的本质就是不断的拆分重构:分的过程是把系统拆分为各个子系统/模块/组件,拆的时候,首先要解决每个组件的定位问题,然后才能划分彼此的边界,实现合理的拆分。合就是根据最终要求,把各个分离的组件有机整合在一起。拆分的结果使开发人员能够做到业务聚焦、技能聚焦,实现开发敏捷,合的结果是系统变得柔性,可以因需而变,实现业务敏捷。
其实,我觉得最核心还是边界拆分。如何拆,拆的颗粒度要多细,就很考验一个架构师对业务和底层技术的掌控程度。一个好的架构师,会让整个系统边界清晰,泾渭分明,功能没有多少重叠的。(不知道何时才能成长为一名架构师(┬_┬))
微服务架构
简单来说,微服务架构是 SOA 架构思想的一种扩展,更加强调服务个体的独立性、拆分粒度更小。
下面这个图,也是上次给公司内部培训PPT上的,我觉得可以能好的概括出何为微服务:
其实服务化架构已经可以解决大部分企业的需求了,那么我们为什么要研究微服务呢?
先说说它们的区别;
微服务架构强调业务系统需要彻底的组件化和服务化,一个组件就是一个产品,可以独立对外提供服务
微服务不再强调传统SOA架构里面比较重的ESB企业服务总线
微服务强调每个微服务都有自己独立的运行空间,包括数据库资源。
微服务架构本身来源于互联网的思路,因此组件对外发布的服务强调了采用HTTP Rest API的方式来进行</