本篇主要探讨以下几个问题:
• 什么是微服务?
• 微服务该怎么做?
• 微服务相关技术、工具
一、什么是微服务?
微服务就像活字印刷一样,每一个服务都是一个组件,通过编排组合的方式来试验,从而真正做到了独立、解耦、组件化、易维护、可复用、可替换、高可用。最终达到提高交付质量、缩短交付周期的效果。
微服务身上可以打上如下的一些“标签”,这些标签充分的说明了微服务的特点。
• 单一职责:每个服务各司其责,对应着唯一的业务能力
• 微:麻雀虽小五脏俱全。服务进一步细化到API级别。
• 面向服务:一系列服务接口API,解除了与平台或语言的绑定。
• 自治:团队独立、技术选型灵活、前后端分离、数据库分离、部署独立、容错(故障隔离)
• 易扩展:可以实现局部强化,针对特定服务进行扩展。
• 流程化:“流水线作业“。遵循开发标准和流程。
二、微服务该怎么做?
是否选择采用微服务并不是一个很难决定的问题,但如果我们选择了采用微服务架构,应该怎么做?
• 业务拆分,体现在设计环节:在设计的时候,要有足够的判断力来合理的规划服务之间的界限。
• 服务治理,底层技术的支持:首先要选一款适合自己实际情况的分布式服务基础框架,对于服务的发现、治理、熔断、降级,都要做好相应的技术准备。
• 自动测试:服务一个明显的表象就是随着服务的增多,如果继续沿用传统的测试模式就会遇到瓶颈,为了保证高效的迭代,尽量做到更多的环节实现自动化。
• 独立部署:微服务拆分之后,每个服务都可以独立部署,进而言之应该是随时随地可以升级和扩展。
• 监控:包括硬件环境、服务状态、系统健康度、接口调用情况、异常的实时告警以及潜在问题的事先预警等等。监控在实施微服务过程中会重要到什么程度呢?一句话:没准备好监控,就不要搞微服务。
我们在来看看这之中一个最常见的问题,微服务该如何拆分呢?
拆分的基础是对于所要建立的系统功能的全面理解:识别不同的业务主体、流程环节,不同类别的业务主体进行分隔;识别整个系统的业务功能点,从上到下,从大到小进行细分,合并相关业务功能。
可以通过以下指标来识别出所有需要拆分的对象,这些不同的主体或是业务功能将作为独立的服务被拆分出来,其目的就是为了实现微服务的单一职责、未来可独立扩展。
★ 公共的业务功能
★ 代表未来业务发展的方向的重点业务
★ 对系统影响大的业务功能
★ 经常变化的业务主体
★ 特殊业务主体
而拆分的粒度是否合适,服务的边界是否清晰,需要通过大量的微服务项目经验和反复的拆分过来掌握,通俗的说,也就是一个熟能生巧的过程。
以下是一个简单的拆分案例,值得注意的是,健康状况服务本可属于详情服务,但从此类信息的业务属性来说,侧重于故障,和基本信息又不是完全一致,所以拆分出来。
三、微服务相关技术、工具
Spring Cloud是一个相对比较新的微服务框架,图示如下:
★ 注册中心:Eureka Server
★ 承载所有服务的注册与发现功能
★ 网关:Zuul
★ 为前台提供后台服务的一个统一出口,同时负责鉴权、认证、安全和跳转
★ 客户端负载均衡:Ribbon
★ 通过负载均衡的策略将请求分发给不同实例处理,减少对服务端的压力
★ 配置中心:Config Server
★ 让用户把配置放在远程服务器上,集中管理集群配置。
在此架构下,一个微服务的被请求和执行的过程如下所示:
为了提高服务的容错能力,追踪服务执行情况,还有以下一些相应工具:
•断路器:Hystrix, 容错管理工具,通过隔离、控制服务对延迟和故障提供容错能力,避免整个系统被拖垮;也可在资源紧张的时候,对边缘服务进行降级处理,拒绝用户访问,但返回一个结果。
• 服务追踪:Sleuth,微服务架构中要完成一个功能,整个调用过程中会聚合多个后台服务协同完成,因此,要跟踪和记录这些请求的调用情况。清楚的知道调用关系及每一个调用环节的时长,出现问题时便于定位。
四、微服务的应用目标
业务层面:
★ 持续交付:通过自动化工具构建持续集成和交付的环境。
★ 业务敏捷:通过快速响应、敏捷开发、持续交付,做到业务敏捷
★ 独立演进:每个服务在保持原有产品能力的基础上不断进化
系统层面:
★ 高可用:关键业务隔离、熔断机制保障,达到系统高可用
★ 高性能:高并发和高性能通过自由伸缩来实现
★ 站在云端:基于容器技术的云服务将简化微服务创建、集成、部署和运维流程
赏
析
微信号:海油小e
加关注
海油小e
微微IT一下, 很海油!
领取专属 10元无门槛券
私享最新 技术干货