微服务架构
什么是微服务
微服务是一种系统架构上的设计风格,它的主旨是架构将一个原本独立的系统拆分成多个小型的服务,每个服务都在各自的进程中运行(可以在不同物理机器上),每个小型服务可以独立部署运行,服务之间通过基于HTTP的RESTful API进行通信协作. 每个服务都是基于业务场景中一些耦合度业务而构建的。由于是轻量级的通信协作，这些微服务可以使用不同的语言进行开发。例如一个电商平台，其中用户中心与订单中心可以拆分为两个微服务.
用微服务可以解决什么问题
微服务所要解决的问题，及传统独立系统所面临的问题，如复杂性高、技术债务、部署频率低、可靠性差、扩展性差、阻碍技术创新。
- 复杂性高：当一个项目达到一定的程度，整个项目的模块肯定很多，模块的边界模糊，依赖关系复杂不清晰，等等，这使得每次代码的更新都是非常痛苦的。
- 技术债务：随着时间推移、需求的变更、人员的变更等，在单体应用中会形成技术债务。
- 部署频率低：单体应用随着代码量的不断增多，项目构建和部署的时间也会变长。在传统单体应用中，每次很小的需求便更与BUG修复，都出触发整个项目的重新构建于部署，从而导致，每次部署的变更较大，BUG修复较大，导致部署出错率较大。
- 可靠性差:整个应用中如一处出现BUG ，可能导致整个应用的崩溃。
- 扩展性差：单体应用的扩展，只能作为整体扩展，而不能根据具体需要扩展模块进行扩展。
- 阻碍技术创新：单体应用中一般都是用同一的技术架构与方案去解决相关问题，团队中每个人都必须使用约定的语言与开放方式，如想引入新的技术架构，非常困难。
与单体系统的区别
传统的业务实现是使用一个单体项目来实现复杂的业务需求,通常一个项目中会分为三个部分,数据库,服务端,前段.在业务初期,所有的业务逻辑放在一个应用中,但随着企业的发展,业务需求会不断增加,系统的复杂度也随之增加,也变得越来越臃肿.同时业务代码关联在一起,技术升级的修改成本过高.另外,单体程序部署在一个进程内,一个小的修改可能需要重新部署而影响其他服务的运行.系统变得越来越难维护和管理.
微服务架构将单体系统根据功能拆分为不同的服务模块,每个模块可以独立部署,模块之间有稳固的边界,每个服务的更新都不会影响其他服务,同时由于是独立部署的,可以更容易地发现系统的瓶颈位置.
微服务带来的新问题
-
运维的新挑战:拆分出的多个微服务使得服务数量变大,整体系统发生故障的概率增大,运维需要负责的工作量急剧上升,因此需要自动化运维的技术来实现自动发现问题,自动分析问题,自动解决问题的功能.同时每个微服务也需要提供监控接口用于提供分析数据,这在一定程度上增加了服务器的负担.
-
接口的一致性:虽然拆分了服务,但服务之间的依赖并不会消除,只是从原来代码依赖的形式变化为服务间的通信依赖,一旦通信双方中的一方需要修改通信接口,那么另外一方也需要进行相应的修改,因此我们需要实现完善的接口和版本管理,并严格地遵循开闭原则(对扩展开放,对修改封闭).
-
分布式的复杂性: 多个独立部署的服务带来了分布式的相关问题,这是微服务架构系统设计中需要考虑的重要因素,如网络延迟,分布式事务,异步消息等.
微服务架构九大特性
服务组件化
组件是一个可以独立更换或升级的单元,就如同主板上的CPU,内存,硬盘等,独立更换或升级不会影响其他组件.
在微服务架构中需要对服务进行组件化分解,服务是一种进程外的组件.
按业务组织团队
当决定进行服务拆分时,通常也意味着要开始对团队进行重新规划与组织.以往的方式会从技术层面将团队划分为,DBA团队,运维团队,后端团队,前端团队
,设计师团队等.以这种方式划分时,可能是一个非常简单的变动,就需要整个团队都做出相应的修改.
在采用微服务架构时,每一个微服务都是针对特定业务的宽栈或是全栈的实现,既要负责数据的持久化存储,又要负责用户接口定义等各种跨专业领域的职能.因此面对大型项目的时候,对于微服务团队的拆分更加建议按业务线的方式拆分,一方面可以有效减少服务内部修改所产生的消耗,另外一方面团队边界可以变得更为清晰.
做产品的态度
在实施微服务架构的团队中,每个小团队都应该以产品的方式,对其产品的整个生命周期负责.而不是以项目的方式,以完成开发与交付并将成果交给维护者为最终目标.
开发团队通过了解服务在具体生产环境中的情况,可以增加他们对具体业务的理解.很多时候一些业务中发生的特殊情况或异常,开发者可以比产品经理更了解特殊的潜在问题或需求.
智能端点和哑结点
在单体应用中,组件间直接通过函数调用的方式进行协作交互,而在微服务架构中,组件间通信的方式发生了改变,若仅仅将原本在进程内的调用改成RPC方式,会导致微服务之间发生繁琐的通信,因此我们需要更粗粒度的通信协议.
在微服务架构中,通常会用以下两种方式调用服务.
- 使用HTTP的RESTful API或轻量级的消息发送协议,实现信息传递与服务调用触发
- 通过轻量级消息总线传递消息,类似RabbitMQ等一些提供可靠异步交换的中间件
去中心化治理
采用集中化的架构治理方案时,通常会在技术平台上制定统一的标准(如统一的OS,统一的数据库等等),但是每一种技术平台都有其短板,在碰到短板时,不得不花大力气去解决,并且可能因为解决的不好最终成为系统的瓶颈.
在实现微服务时,通过约定好采取轻量级的接口,我们对于服务本身的技术平台不再那么敏感,每个服务可以结合自身的需求和特点选择合适的.
去中心化管理数据
在实现微服务时,希望让每一个服务都管理其自身的数据库,这就是数据的去中心化.
在去中心化过程中,除了将原数据的存储内容拆分到新的同平台的其他数据库实例中(如把原本存储在MySQL中的表拆分后,存储到多个不同的MySQL实例中),也可以将一些具有特殊结构或者业务特性的数据存储到一些其他技术实现的数据库实例中(如把日志信息存储到MongoDB中或把用户登录信息存储到Redis中)
基础设施自动化
近年来云计算服务于容器化技术的不断成熟使得运维工作变得越来越容易.但是在微服务架构中,每个服务的个头变小了,而数量却成倍增长.这使得运维人员需要关注的内容也成倍增长,并且操作性任务也会成倍增长.
所以在微服务架构中,务必从一开始就构建起"持续交付"平台来支撑整个实施过程,该平台需要量大内容.
- 自动化测试:每次部署前的强心剂,尽可能地获得修改的信心
- 自动化部署:解放繁琐枯燥的重复操作以及对多环境的配置管理
容错设计
在微服务架构中,快速检测出故障源并尽可能地自动恢复服务是必须被设计和考虑的.通常我们希望在每个服务中实现监控和日志记录,比如服务状态,断路器状态,吞吐量,网络延迟等关键数据和仪表盘等.
演进式设计
要实施一个完美的微服务架构,需要考虑和设计的成本并不小,对于没有足够经验的团队来说,甚至比单体应用付出更多的代价.
所以在很多情况下,架构师都会以演进的方式进行系统的构建.在项目初期,单体系统可以在有限成本和时间的限制下满足需求,并且构建和维护的成本都不高.但随着业务的不断发展,架构师会将一些经常变动或者具有一定时效性的内容进行微服务处理,并将原来单体系统中多变的模块逐步拆分出来,而稳定不太变化的模块就形成一个核心微服务存在于整个架构中.