微服务
什么是微服务
微服务的概念是在2014年由 Martin Fowler 提出的,他定义了以单一应用程序构成的小服务,自己拥有自己的进程和轻量化处理,服务依据业务功能设计,以全自动方式部署,与其它服务使用 Http Api 通信,同时服务会使用最小规模的集中管理能力,还可以用不同编程语言与数据库等组件实现。
架构的演变
互联网早期到现在,系统架构大致经历了下面几个过程。
单体应用架构
把所有的功能都集中在一个应用中,统一部署,开发成本、部署成本、维护成本低。
- 优点:项目架构简单,适合用户量较少的项目,开发成本低,项目部署在一个服务器节点上,维护方便;
- 缺点:功能集中在一个工程上,相比于大型项目,项目模块紧耦合,单点容错率低,无法对不同功能模块进行正对性的优化和水平拓展。
垂直应用架构
把之前的单体应用拆分成多个应用,以提升效率。例如电商系统可以拆分成电商系统、后台系统等。
- 优点:项目拆分实现了流量分担,解决并发问题,而且可以针对不同模块进行优化和水平拓展,同时不同系统之间不会互相影响,提高容错率。
- 缺点:系统之间互相存在,无法互相调用,而且系统互相独立,会造成一部分功能冗余。
分布式架构
随着业务的增加,在垂直应用架构中冗余的业务代码越来越多,就需要将冗余部分抽取出来,统一做成业务层单独处理,变成一个单独的服务,控制层就能调用不同的业务层完成不同的业务功能,就是一个项目拆分成两个部分,表现层和服务层,服务层包含业务逻辑,表现层只负责和页面的交互,这就是分布式。
- 优点:提高代码的复用性,将公共的功能集中在业务层。
- 缺点:系统耦合度高,调用关系复杂,不好维护。
SOA架构
Service Oriented Architecture 简称SOA,意思是面向服务体系结构,是资源调度和服务治理的治理中心。
- 优点:使用治理中心(ESB\dubbo)解决了服务见调用关系的自动调节。
- 缺点:服务间会有依赖关系,一旦某个环节出错会影响较大(服务雪崩),服务关系复杂,运维、测试部署困难。
微服务架构
微服务架构在某种程度上是SOA架构持续发展的成果。它更加强调服务的更细化的拆分,最终目的就是调高效率,它的每个服务必须独立部署而且不能互相影响。比较轻量级。
- 优点:服务原子化拆分,独立打包、部署和升级,保证每个微服务清晰的任务划分,利于扩展。
- 缺点:分布式系统开发的技术成本高(容错、分布式事务等),复杂性更高,每个微服务进行分布式独立部署,当进行模块调用的时候,分布式将会变得更加麻烦。
微服务架构与SOA架构的不同
- 微服务架构比SOA架构更加精细;
- 微服务架构中每个服务需要独立部署;
- SOA架构会发生存储共享,微服务每个服务是单独的数据库;
- 微服务架构粒度比较精细,可以快速迭代版本。
总结
微服务分工明确,清晰的任务划分,可以提升性能。