带你快速了解微服务

微服务架构在近几年一直很热门，尤其是随着敏捷开发、持续集成交付、DevOps、云技术、虚拟技术docker化等的深入人心，经常能在技术论坛，博客上看到相应的文章推送。正好现在我们公司使用的也是微服务架构，将一个原本巨大的单体应用进行拆分（比如金币服务，用户中心，有提供给PC、客户端、H5的服务等），用RPC框架进行微服务之间的通讯以及服务治理。今天简单的总结一下对微服务架构设计的理解。

微服务的风靡肯定是有原因的，没有对比就没有伤害。我们知道传统的开发单体式应用，随着系统变得越来越大，最终会达到一个临界点，作为一个单体它变得难以管理。每一行代码的添加，都会让系统变得更加难以理解、变更和重用。

 

我们知道单体应用比较适合小项目，开发简单直接，集中式管理基本不会重复开发，功能都在本地，没有分布式的管理开销和调用开销。但是一个简单的应用会随着时间推移逐渐变大，单体式应用的不足有：

• 敏捷开发和部署举步维艰，其中最主要问题就是这个应用太复杂，以至于任何单个开发者都不可能搞懂它。因此，修正bug和正确的添加新功能变的非常困难，并且很耗时。

• 单体式应用也会降低开发速度；应用越大，启动时间会越长。

• 复杂而巨大的单体式应用也不利于持续性开发。

• 单体式应用在不同模块发生资源冲突时，扩展将会非常困难。

• 单体式应用另外一个问题是可靠性。因为所有模块都运行在一个进程中，任何一个模块中的一个bug，比如内存泄露，将会有可能弄垮整个进程。除此之外，因为所有应用实例都是唯一的，这个bug将会影响到整个应用的可靠性。

• 单体式应用使得采用新架构和语言非常困难。

 

我们都有过这样的经历，一开始你有一个很成功的关键业务应用，后来就变成了一个巨大的，无法理解的怪物。因为采用过时的，效率低的技术，使得雇佣有潜力的开发者很困难。应用无法扩展，可靠性很低，最终，敏捷性开发和部署变的无法完成。那么如何应对呢？

 

自然微服务应运而生，微服务是一种架构风格，一个大型复杂软件应用由一个或多个微服务组成。系统中的各个微服务可被独立部署，各个微服务之间是松耦合的。每个微服务仅关注于完成一件任务并很好地完成该任务。在所有情况下，每个任务代表着一个小的业务能力。

 

微服务的概念源于2014年3月Martin Fowler所写的一篇文章 Microservices。尽管“微服务”这种架构风格没有精确的定义，但其具有一些共同的特性，如围绕业务能力组织服务、自动化部署、智能端点、对语言及数据的"去集中化"控制等等。微服务架构的思考是从与整体应用对比而产生的。

 

因此微服务是一种可以很好的优化复杂问题的架构，将一个庞大的需求，拆解成不同的服务。例如之前提到的金币服务中心、用户账号中心、客户端API中心等等，每个服务互相独立，单独部署。这样每一个系统完全独立，功能相对单一，每个系统之间各司其职。对于开发和维护都会变得更加可控。

 

听上去好像都不错，具体怎么落地啊？这需要回答下面几个问题：

• 客户端如何访问这些服务？

• 服务之间如何通信？

• 这么多服务，怎么找?

• 服务挂了怎么办？

 

原来的单体应用，所有的服务都是本地的，UI可以直接调用，现在按功能拆分成独立的服务，跑在独立的一般都在独立的虚拟机上的进程了。客户端UI如何访问他的？后台有N个服务，前台就需要记住管理N个服务，一个服务下线/更新/升级，前台就要重新部署，这明显不服务我们拆分的理念，特别当前台是移动应用的时候，通常业务变化的节奏更快。另外，N个小服务的调用也是一个不小的网络开销。还有一般微服务在系统内部，通常是无状态的，用户登录信息和权限管理最好有一个统一的地方维护管理。

 

所以，一般在后台N个服务和UI之间一般会一个代理或者叫API Gateway，它的作用包括：

• 统一处理与业务无关的通用功能。如：ip限流、流量镜像、ab测试、多环境部署

• 统一处理业务相关的通用功能。如：版本控制、数据缓存、多接口数据聚合

• 提供访问安全机制。如：session验证、url鉴权、黑白名单、

• 提供服务安全机制。如：访问控制、流量控制

• 增加线上容灾机制。如：流量调度、服务降级

 

前面提到，单体方式开发一个很大的风险是，把所有鸡蛋放在一个篮子里，一荣俱荣，一损俱损。而分布式最大的特性就是网络是不可靠的，通过微服务拆分能降低这个风险，不过如果没有特别的保障，结局肯定是噩梦。当我们的系统是由一系列的服务调用链组成的时候，我们必须确保任一环节出问题都不至于影响整体链路。相应的手段有很多：

• 重试机制、限流、熔断机制、负载均衡、降级（本地缓存）

可以说，微服务的优点和缺点一样明显。

优点：开发简单、技术栈灵活、服务独立无依赖、独立按需扩展、可用性高

 

缺点（挑战）：多服务运维难度、系统部署依赖、服务间通信成本、数据一致性、系统集成测试、重复工作、性能监控

我们知道互联网服务，往往很难有完美解决办法，我们会有很多方案去兜底 或 降级 或 熔断，或改产品策略。每一种方案都不是完美的，只有适合自己的才是最好的，因此在面对业务需求的时候，也需要根据实际情况去选择不同的架构，单体和微服务本身没有对错，关键还在于不同的场景如何运用，最适合的才是最好的。

 

欢迎扫码，关注我的微信公众号