微服务和GRPC

微服务

什么是微服务

转载自http://www.qziedu.cn/xinxizhongxin/xxzx_kjqy/2019-04-11/12954.html

​ 大半年前，我第一次听说【微服务】这个词，当时由于好奇心，就 Google 了一下这个词，从此埋下了一颗学习微服务的心。在前半年的时间里因为忙，所以抽不出完整的时间块来学习微服务。但都有使用闲碎的时间来看相关的概念与架构。最近总算是有点时间了，我觉得光看概念是没有用的，要真真实实地实践一下，才能真正学到东西。这才有了这篇文章（后面会有系列文章）。

什么是微服务

我们就以微信为栗子，来解释一下微服务。首先假设你要做一款简化版的微信产品，他只有如下几个功能。那么你的初期系统设计应该是这样的：

微信单体架构

随着时间的迁移，我们日子来到了 2019.01.01 00:00 跨年，此时此刻，很多人都在发朋友圈。朋友圈接口访问量很大，服务器访问峰值瞬间冲顶，那么我们可以开始做集群操作。

也就是整一个服务器做集群操作。那么我们的注册登录接口、支付接口、聊天接口也有了一个复制集，在此时此刻这几个接口是比较鸡肋的，没有很大的访问量**，**那我们能不能只将朋友圈的接口做扩容呢？答案当然是可以的，且看下图 – 微服务架构

微信微服务架构

那么当我们微服务架构遇到 2019.01.01 00:00 跨年，会怎么样呢？直接水平扩展朋友圈服务，如下图，峰值压力有所缓解。

微信微服务架构

然而在各个功能拆解成一个个的服务之后，由客户端直接访问各个微服务，这样就直接将我们的服务暴露了出来，客户端也需要定制相应的访问策略。这样的设计还是没有那么友好。那么，我们能不能将所有微服务统一到一起呢？且看下图：

微信微服务架构plus

在这张示例图中，多了一个 APIGateway 模块，那 API 网关是用来干嘛的呢？

一般情况下 API 网关有以下任务：路由，安全，限流，缓存，日志，监控，重试，熔断等，然后服务层就纯粹的做业务，也能够很好的保证业务代码的干净，不用关心安全，压力等方面的问题。

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

维基百科对微服务的定义

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

微服务的特征与优势

微服务特征：单一职责；轻量级的通信；隔离性，运行在自己的进程中，不会相互干扰；有自己的数据，数据的独立性，每个微服务都有自己的数据库；技术的多样性，选用适合的技术做合适的事。

一个微服务就负责某一个职责，就像朋友圈服务，它就只负责朋友圈的【增删查】功能，与其他服务独立开来，可以选用不同的技术语言，来满足不同的需求。

微服务的优势：独立性、敏捷性、技术栈灵活、高效团队

微服务的不足

额外的工作、数据一致性、沟通成本、debug 单元测试困难、需要额外工作。

狂神GRPC

单体架构：所有都在一个服务器上

微服务架构：拆分成多个服务

码神之路GRPC