引言

今天将围绕“微服务架构”，来回顾一下它的原理及特征。首先在学习一个事物前，我们要首先问自己它是什么、为什么、以及我们怎么做等一些基础架构性的问题。本笔记也将会大致按照这样的脉络进行演进记录。

早期的互联网具有用户少、并发量低、数据量低等不复杂的需求。大多只需要单个的服务器即可满足所需，而数据库和文件服务部署在外部单个服务器上。比如下图的server应用、文件服务、数据库均为单体服务，缺乏故障转移，在升级维护中必须进行停机，可用性低。因此在现在的业务场景中已经不再适用。这就是最早互联网架构，现在的架构也是从最初的架构演进发展而来的。

单体架构

现如今，互联网厂商日常面临庞大的用户量，日均数十亿PV的高并发和PB级别的数据存储等问题的挑战。程序员们同时要求保证系统的高可用和弹性伸缩，并且能够根据需要进行快速迭代扩展，这些都对于系统架构提出了很高的要求。

基于基础的架构，系统架构的部分演进路线如下：

微服务架构是什么？

微服务架构是一种在SOA基础上彻底服务化的一个自下而上的系统架构。微服务架构全貌：

在日常的经验甚至是各种踩坑后我们发现：只要抓住服务治理、监控的观测性和安全验证这三点要素，我的系统架构开发就不会出现大的问题。

为什么用微服务架构？

为什么这个问题就牵扯到微服务架构原理及特征方面了：服务和实例

服务：一组具有相同逻辑的运行实体，运行实体即是实例
实例：个服务中，每个运行实体即为一个实例。实例和通常的进程没有硬性的对应要求，但一般表现为一个实例对应多个进程。也就是用多个进程共同干一件事情的意思。

我们的代码是这样部署到服务端的

这里还涉及到HDFS开发知识

对应到微服务里，HDFS不是一个服务，这里的NameNode是一个服务，DataNode是另一个服务，区别在于单实例的服务。

服务之间是如何进行通信的呢？

首先由于微服务拆分多个服务的意义所在，所以微服务之间的服务是需要进行通信的。对于单体服务，不同模块通信只是简单的函数调用对于微服务，服务间通信意味着网络传输。经常用到的通讯协议是http/gRPC。

问题

通讯需求：服务A调B，涉及到hardcode

// Service A wants to call service B.
client := grpc.NewClient( “10.23.45.67:8080" )
// 问题：
        1.此B服务地址是动态变化的
        2.如下所示 服务A的请求只会指挥B的某一个实例，无法执行其余的实例

如果引入DNS呢？

这样是可以的，但是存在以下问题

- 本地 DNS 存在缓存，导致延时---->一个字，慢
- 负载均衡问题---->还得解决用域名的统计概率问题（逮住一个用也是不行的嘛
- 不支持服务实例的探活检查---->得试一试这个IP是不是能用
- 域名无法配置端口

DNS不行，那如果我弄个相似的呢？

借用DNS的思想，搞个类似hash表去分配端口不就解决了？

解决思路: 新增一个统一的服务注册中心，用于存储服务名到服务实例的映射。增加一层服务的注册中心用random实现的随机平均。

简单地使用

服务实例上线及下线过程（针对service B 的 insrance-3

删掉Service Registry中的第三份 addr，经过一定延迟后会下线了实例3。上线实例也是这样，不过还得进行healthcheck进行基本的default

微服务架构原理及特征 | 青训营笔记

引言