什么是微服务
微服务有什么好处
解耦:对于我们底层程序员而言,看得见的好处就是解耦。我要实现一个功能,可能并不需要很深入的了解别人的代码,因为程序员嘛,可能都觉得别人的代码是个渣渣([哭笑不得])。我可以新作一个微服务,这个服务为其他功能提供服务,又不依赖于原来已有的功能,至于业务逻辑,可以一边上手一边熟悉
内聚,可以独立部署:意思就是我维护的这个微服务,可以独立部署,对其他服务不会是强依赖,不会存在因为其他服务不存在而造成我自己的服务不能启动或者不可用的问题
分布式:微服务架构下不存在一个特别大的系统包含很多中心功能,这样也能提高容错性,一个服务的瘫痪并不会让整个系统瘫痪
数据分开治理,自带分库属性:原来的大系统使用一个数据库,当数据很多流量很大时,就会涉及到分库分表。而微服务下,每个服务是否使用数据库,数据库是和其他服务公用还是自建,都有很大灵活性,即我觉得微服务自带分库分表属性
各个模块的单元测试容易自动化
等
微服务面临的挑战
-
图1 - 客户端与服务端的通信需要一个 API GateWay:通常情况下,客户端和微服务们不在一起,而各个微服务会集中部署在一个机房,那微服务之间的互相调用是很快速的,但是客户端和微服务之间的调用会是耗时的。而且,用户的一个动作不能在客户端进行多次连续调用,这样一来速度慢,二来会有泄漏系统架构的风险。
-
通常情况下,在客户端和微服务架构之间会有一个API GateWay,如图1变成图2所示,GateWay最重要的作用是为客户端提供后台服务的聚合,提供一个统一的服务出口,解除他们之间的耦合,为了解决API Gateway单点故障点或者性能瓶颈,通常Gateway也是一个集群,而且客户端的访问控制、账号管理、登录管理等切面通常会在这里处理。
图2 - 微服务很多时,整个链路可能很长,调用失败的风险高,而且e2e自动化测试会成为一个问题
- 服务注册和服务发现,我司有自己的服务管理系统。
- 分布式事务,这个是微服务系统的大难点,可能需要根据自己系统的情况和业务需求进行定制了,我推荐补偿性分布式事务和基于消息的分布式事务。