# 微服务 ## 单体应用 相对的,要理解什么是微服务,那么可以先理解什么是单体应用,在没有提出微服务的概念的“远古”年代,一个软件应用,往往会将应用所有功能都开发和打包在一起,那时候的一个B/S应用架构往往是这样的: ```mermaid flowchart LR A[Client] <---> B[Browser] B <---> C[Server] ``` 但是,当用户访问量变大导致一台服务器无法支撑时怎么办呢?加服务器加负载均衡,架构就变成这样了: ```mermaid flowchart LR A[Client] <---> B[Browser] B <---> C[LoadBalance] C <---> D[Server1] C <---> E[Server2] ``` 后面发现把静态文件独立出来,通过CDN等手段进行加速,可以提升应用的整体相应,单体应用的架构就变成: ```mermaid flowchart LR A[Client] <---> B[Browser] B <---> C[LoadBalance] C <---> D[Server1] C <---> E[Server2] F([html/js/css]) F -.-> B G[CDN分发] --> F H[静态资源服务器] H <--> G ``` 上面3中架构都还是单体应用,只是在部署方面进行了优化,所以避免不了单体应用的根本的缺点: - 代码臃肿,应用启动时间长;(代码超过1G的项目都有!) - 回归测试周期长,修复一个小小bug可能都需要对所有关键业务进行回归测试。 - 应用容错性差,某个小小功能的程序错误可能导致整个系统宕机; - 伸缩困难,单体应用扩展性能时只能整个应用进行扩展,造成计算资源浪费。 - 开发协作困难,一个大型应用系统,可能几十个甚至上百个开发人员,大家都在维护一套代码的话,代码merge复杂度急剧增加。 ## 微服务 我认为任何技术的演进都是有迹可循的,任何新技术的出现都是为了解决原有技术无法解决的需求,所以,微服务的出现就是因为原来单体应用架构已经无法满足当前互联网产品的技术需求。 在微服务架构之前还有一个概念:SOA(Service-Oriented Architecture)-面向服务的体系架构。我认为的SOA只是一个架构模型的方法论,并不是一个明确而严谨的架构标准,只是后面很多人将SOA与The Open Group的SOA参考模型等同了,认为严格按照TOG-SOA标准的才算真正的SOA架构。SOA就已经提出的面向服务的架构思想,所以微服务应该算是SOA的一种演进吧。 撇开架构先不说,什么样的服务才算微服务呢? - 单一职责的。一个微服务应该都是单一职责的,这才是“微”的体现,一个微服务解决一个业务问题(注意是一个业务问题而不是一个接口)。 - 面向服务的。将自己的业务能力封装并对外提供服务,这是继承SOA的核心思想,一个微服务本身也可能使用到其它微服务的能力。 ## 微服务的典型架构 微服务架构,核心是为了解决应用微服务化之后的服务治理问题。 应用微服务化之后,首先遇到的第一个问题就是服务发现问题,一个微服务如何发现其他微服务呢?最简单的方式就是每个微服务里面配置其他微服务的地址,但是当微服务数量众多的时候,这样做明显不现实。所以需要使用到微服务架构中的一个最重要的组件:**服务注册中心**,所有服务都注册到服务注册中心,同时也可以从服务注册中心获取当前可用的服务清单: 目前国内企业使用的微服务框架主要是Spring Cloud和Dubbo(或者DubboX),但是Dubbo那两年的停更严重打击了开发人员对它的信心,Spring Cloud已经逐渐成为主流,比较两个框架的优劣势的文章在网上有很多,这里就不重复了,选择什么框架还是按业务需求来吧,业务框架决定技术框架。 Spring Cloud全家桶提供了各种各样的组件,基本可以覆盖微服务的服务治理的方方面面,以下列出了Spring Cloud一些常用组件: ```mermaid flowchart LR A[Spring Cloud] A --- B[Spring Cloud Gateway 服务网关] A --- C[Spring Cloud Config 服务配置] A --- D[Spring Cloud Consul 服务注册] A --- F[Sping Cloud Sleuth 服务调用链跟踪] A --- G[Spring Cloud OpenFeign 用于服务间的RESTful API调用] A --- H[Spring Cloud Netflix 熔断,注册,网关,负载均衡] ```