微信微服务架构plus

在这张示例图中，多了一个 APIGateway ，那 API 网关是用来干嘛的呢？
一般情况下 API 网关有一下任务：路由，安全，限流，缓存，日志，监控，重试，熔断等，然后服务层就纯粹的做业务，也能够很好的保证业务代码的干净，不用关心安全，压力等方面的问题。

当然，以上示例图只是一个小小的演示，真实的使用中，要比这个复杂得多，这里只是先抛出概念，供大家理解。

维基百科对微服务的定义:

微服务 (Microservices) 是一种软件架构风格，它是以专注于单一责任与功能的小型功能区块 (Small Building Blocks) 为基础，利用模组化的方式组合出复杂的大型应用程序，各功能区块使用与语言无关 (Language-Independent/Language agnostic) 的 API 集相互通讯。

微服务的特征与优势

微服务特征：

1. 单一职责；
2. 轻量级的通信；
3. 隔离性，运行在自己的进程中，不会相互干扰；
4. 有自己的数据，数据的独立性，每个微服务都有自己的数据库；
5. 技术的多样性，选用适合的技术做合适的事；
   一个微服务就负责某一个职责，就像朋友圈服务，它就只负责朋友圈的【增删查】功能，与其他服务独立开来

微服务的优势：

• 独立性
  每个微服务的构建、部署、扩容、缩容、数据库都是独立的。数据库表修改时，互补影响。
• 敏捷性
  功能单一、可快速添加新需求
• 技术栈灵活
  可以发挥不同语言的优势，例如：用 python 来爬数据，nodejs 来处理 io 流
• 高效团队
  可以分发给不同的团队进行开发

微服务的不足

1. 额外的工作；
2. 数据一致性；
3. 沟通成本；
   需要额外工作，例如：服务的拆分（即如何拆分微服务，哪些服务应该拆到一起）、服务注册、服务发现、微服务间的通信。每个微服务都持有独立的数据库，无法做到数据强一致性，只能做到最终结果一致性。做微服务也会增加团队的沟通成本。

微服务通信方式

微服务可以使用两种基本消息传递模式 -- 同步与异步消息传递，来与其他微服务通信。

1. 同步通信。 在此模式下，一个服务使用 HTTP 或 RPC（Remote Procedure Call，翻译过来为“远程过程调用”） 框架等协议调用另一个服务公开的 API。 此选项之所以称作同步消息传递模式，是因为调用方需要等待接收方返回的响应。比较通用的 RPC 框架有：gRPC（Google）、Thrift（Apache）

2. 异步消息传递。 在此模式下，服务可以在不等待回应的情况下发送消息，然后一个或多个服务以异步方式处理该消息。比较流行的消息队列有：RabbitMQ、ZeroMQ、Kafka、ActiveMQ
   至于具体怎么通信，后面会有详细的分享。本文只是先介绍微服务如何通信。

我们应该使用微服务吗？

微服务已经成为一种热门的架构模式了，打开各大技术类网站几乎都少不了微服务的身影。但微服务真的适合我们当下的用户规模与公司级别吗？这个问题，其实也没有比较统一的答案。在我看来，其实大部分小公司是用不到微服务的，因为其不足远大于其优势，单体应用做好优化、数据库读写分离、集群、负载均衡，就能应对日常的流量。当你以上的优化都做了，还是撑不住压力的话，就可以考虑微服务了。当然，服务架构选型还是看不同情况和公司意志的，如果有必要做跨语言等其他需求，那就做微服务的。

后记

最后，抛开业务上的原因，我们作为技术人也需要学习微服务相关的技术，不能局限于用不上就不学习。在当下大环境下，储备多一点知识，提高自身竞争力总是没有坏处的。
个人的知识储备总是有限的，如有错误的地方，还请大佬斧正。点击阅读原文，链接到我的知乎，我会在知乎上对文章错误的地方进行修改。

本篇文章首发于公众号「zone7」，关注公众号获取最新推文。