微服务架构-01

我们先要谈一谈系统架构的演变:

1.单体应用架构:

互联网行业的早期的WEB工程,是将所有功能(前端UI,controller层,service层,dao层)放到一个WEB容器中运行,这种架构被称作单体应用架构,这种架构的优点在于多有功能都集成在一个项目中,项目的架构统一,简单,前期的开发成本低,周期较短,一般是小型项目的首选;但是这种架构的缺点同样明显:项目所有功能集成在一个项目中,不易开发,扩展以及维护,WEB项目当访问量逐渐增大,系统服务速度会明显下降,如果要提升系统的性能只能通过固件集群节点,成本高,并且有硬件瓶颈,所以就有了接下来的垂直应用架构.

2.垂直应用架构:

这时候我们就在想:我们整体一个项目,总有几块的流量特别大,有些就相对较小,我们可不可以将我们的应用拆成几个应用呢?答案是肯定的,这就是垂直应用架构.这种架构的优点是项目架构简单,功能趋向一致,便于开发,维护,并且通过合理的拆分,项目也不至于过大,并且在不同的项目之间可以采用不同的技术实现,但是这种架构同样有缺点:对大型项目开发和维护困难,系统性能扩展只能通过集群,成本高,并且也存在硬件瓶颈.

3.分布式SOA架构

这时就出现了分布式SOA架构,SOA(全称Service-Oriented-Architectrue,即面向服务的架构),它可以根据需求通过网络对松散耦合的粗粒度应用组件进行分布式部署,组合和使用.一般通常每一个服务是以一个独立的进程存在于操作系统之中.从功能的角度上考虑,把业务逻辑抽象成可复用,可组装的服务,通过对服务的调用实现业务的快速再生,提高的灵活性,并且对系统从业务级别进行了解耦,我们很明显能看出SOA架构的优点:抽取公共的功能为服务,提高了开发效率;对不同的服务进行集群化部署,解决了系统压力;基于ESB或者DUBBO协议的调用减少了系统之间的耦合性;但是它也存在一定的缺点:抽取服务的粒度过大,服务的提供方和和调用方的接口耦合过大.

4.微服务架构

微服务架构其实是对SOA架构的加强版,微服务架构强调:业务需要彻底的组件化和服务化.原有的单个业务系统会拆成多个独立开发,设计,运行的小应用,通过这些小应用之间的服务完成交互和集成.微服务架构的优点是:通过原子化的拆分,以微服务独立打包,部署和升级,小团队的交付周期大大缩短,运维成本也大幅下降;并且微服务架构遵循单一原则,服务之间采用RESTFUL等轻量级协议传输调用.它的缺点是:如果微服务过多,服务治理成本高,不利于系统维护,而且微服务的开发对技术的成本较高(熔错,分布式事务等)