微服务基础

什么是微服务构架

简单来说,微服务是系统架构上的一种设计风格.它的主旨是将原本一个独立的系统拆分成多个小型服务,这些小型的服务都在各自的独立的进程中运行,服务之间通过基于HTTP 的Restful API进行通信协作.被拆分的每一个小型服务都围绕着系统中的某一项或某一些耦合度较高的业务进行构建,并且每个服务都维护着自身的数据存储,业务开发,自动化测试案例以及独立部署机制,由于有了轻量级的通信协作基础,所以微服务可以由不同语言编写.

微服务带来的问题

• 运维的新挑战
  在微服务架构中,运维人员需要维护的进程数量大大增加,有条不紊的将这些进程编排和组织起来并非易事. 运维过程中需要更多的自动化,这就需要运维人员需要具备一定的开发能力,来编排运维过程并让它们自动运行.(运维成本增加,更需要运维的自动化)
• 接口的一致性
  拆分了服务,业务逻辑上的依赖并不会消除,只是从单体应用中的代码依赖变成了服务间的通信依赖.当我们对接口进行了修改,那么交互双方也需要协调这些改变来发布,以保证接口的正确调用.需要更加完善接口和版本管理.
• 分布式的复杂性
  由于拆分后的各个微服务都是独立部署并运行在各自独立的进程中,它们需要通信来协作.所以分布式环境的问题都是微服务架构系统设计的时候都要考虑的因素,例如网络延迟,分布式事务,异步消息等.

微服务的优点

敏捷开发和自动化部署.

微服务的九大特性

服务组件化

组件是一个可以独立更换和升级的单元,独立的更换和升级不影响其他单元.

按业务组织团队

在实施微服务架构的时候,需要采用不同的团队分割方法,由于每一个微服务都是正对业务的宽栈或全栈实现,即负责数据的持久化储存,又负责用户接口定义等各种跨专业领域的职能.面对大的项目的时候,对于微服务团队的拆分更加建议按照业务线的方式进行拆分,一方面可以减少服务内部修改的内耗,另一方面团队的边界更加清晰.

做产品的态度

在实施微服务架构的团队中,每个小团队都应该以做产品的方式,对其产品的整个生命周期负责.已完成开发与交付并将成果交给维护者以最终目标.

智能端点与哑管道

在微服务架构中,通常会使用一下两种服务调用方式:

• 使用HTTP的RESTful API 或轻量级的消息发送协议,实现消息传递与服务调用的触发.
• 通过轻量级的消息总线上传递消息,类似rabbitMQ等一些提供异步交换的中间件

去中心化治理

中心化治理的弊端
采用中心化治理方案时,通常技术平台都会制定统一的标准,但是每一种技术平台都有其短板,这导致在处理短板时,不得花费大量的精力去处理.
采用去中心治理的优势
在实施微服务架构时,通过采用轻量级的契约定义接口,使得我们服务本身的具体技术平台不在那么敏感,这样整个微服务架构系统中的各个组件就能针对不同的业务选择不同的技术平台.

去中心化管理数据

我们在实施微服务架构时,希望都让每一个服务来管理其自有的数据库,这就是数据管理的去中心化.

去中心化过程中,我们除了将原数据库中的存储内容拆分到新的同平台的其他数据库实例中之外(如把原本存储在MySQL中的表拆分后,存储到多个MySQL实例中),也可以将一些具体特殊结构或业务特性的数据存储到一些其他技术的数据库实例中(如把日存储到MongoDB中或者把用户信息存储到Redis中).

弊端
数据管理去中心化可以让数据管理更加细致化,通过采用更适合的技术可让数据存储和性能达到最优由于数据库存储在不用的数据库实例中,数据的一致性也称为了微服务的架构的问题之一.分布式事务本身的实现难度大,所以在微服务架构中,我们更强调各服务之间的无事务的调用,而对于数据的一致性,只要求最后的处理状态是一致的即可.若在过程中发生错误,通过补偿机制来处理,使得错误数据达到最终一致性.

基础设施自动化

微服务架构中,务必一开始就构建起持续交付的平台来支撑整个实施过程,该平台需要两大内容,缺一不可.

• 自动化测试: 每次部署前的强心剂,尽可能的获得对正在运行的软件的信心.
• 自动化部署: 解决繁琐枯燥的重复操作以及对多环境的配置管理.

容错设计

在微服务架构中,快速检测出故障并尽可能的地洞恢复服务是必须被设计和考虑的.通常我们希望在每个服务中实现监控和日志记录组件,比如服务状态,断路器状态,吞吐量,网络延迟等关键数据的仪表盘.

演进式设计

架构师需要以演进的方式进行系统的构建.