这是我参与「第五届青训营」伴学笔记创作活动的第9天。
前言
在上上一篇的笔记中，我们先认识了一下软件架构，并且通过一个电商系统的画图举例，带大家领略了随着业务场景越来越复杂，架构也在不断地一起进化，并最终发展到了我们如今熟知的微服务。因此，今天的笔记内容主要围绕微服务展开。
知识点内容
1.微服务介绍
关于架构的知识，我在这里就不赘述了，感兴趣或者不了解的话可以去翻前面的内容。首先，我们直接给微服务下个定义，我们可以认为它是一种经过良好架构设计的分布式架构方案。但方案该怎么落地？选用什么样的技术栈？全球的互联网公司都在积极尝试自己的微服务落地方案。
一个微服务架构基本的组件如下：
优点：拆分粒度更小、服务更独立、耦合度更低
缺点：架构非常复杂，运维、监控、部署难度提高（Ps:这里的缺点相对单体架构或者分布式架构来说的，现在运维、监控、部署这些其实还好）
2.微服务的架构特征
主要有以下四点特征：
- 单一职责：微服务拆分粒度更小，每一个服务都对应唯一的业务能力，做到单一职责
- 自治：团队独立、技术独立、数据独立，独立部署和交付
- 面向服务：服务提供统一标准的接口，与语言和技术无关
- 隔离性强：服务调用做好隔离、容错、降级，避免出现级联问题
我在上面提到微服务是一种经过良好架构设计的分布式架构方案，所以其实上述特性就是在给分布式架构制定一个标准，进一步降低服务之间的耦合度，提供服务的独立性和灵活性。做到高内聚，低耦合。
3.微服务的核心
既然微服务它是一种分布式架构方案，那么就引申出了两个关键点：第一：一个系统怎么拆分成各个服务；第二：服务与服务之间怎么进行通信交互数据，搞明白这两个问题，我们也就对微服务有了一定的理解。
3-1.服务拆分
何分布式架构都离不开服务的拆分，微服务也是一样。因此，服务拆分显得尤为重要，是我们一个微服务架构的前置条件，而服务拆分需要遵循这几个原则：①：不同微服务，不要重复开发相同业务；②：微服务数据独立，不要访问其它微服务的数据库；③微服务可以将自己的业务暴露为接口，供其它微服务调用。 为了帮助更好理解，可以结合文字和下图一起看：
3-2.远程调用
既然一个系统被我们拆分成了不同的服务，并且每个服务都有自己的数据库，那么我们在实际部署上线中也是将它们部署在不同的服务器上。因此，服务与服务之间的调用就要依靠网络来实现远程调用，常见的远程调用方式有两种：RPC协议与Http协议。Http大家都已经很熟悉了，这里多提一嘴RPC协议，它允许运行于一台计算机的程序调用另一台计算机的子程序，而程序员无需额外地为这个交互作用编程。说得通俗一点就是：A计算机提供一个服务，B计算机可以像调用本地服务那样调用A计算机的服务。
因此，在服务调用关系中，就会出现两个不同的角色：
服务提供者：一次业务中，被其它微服务调用的服务。（提供接口给其它微服务）
服务消费者：一次业务中，调用其它微服务的服务。（调用其它微服务提供的接口）
如果服务的提供者部署了多个实例，那么服务的消费者又该如何找到提供者以及确保提供者正常运行，这里引申出了注册中心。可以将注册中心理解成一个网关，服务的提供者不管有多少个实例部署，都将自己注册到注册中心，当消费者前来调用时，由注册中心根据策略安排消费者调用提供者，并且所有注册到注册中心的提供者都需要定时向注册中心发送“健康汇报”从而确保分配的提供者都是正常运行的，如下图：
对于微服务的入门，只要理清以上就好，微服务治理那一套暂时了解了解就行，先能写简单的微服务demo再去谈治理吧。
小结
通过对微服务进一步的理解，才能让我们的开发事半功倍。理清服务与服务之间的调用关系，才能明确在开发微服务项目时，我们的业务逻辑写在哪里。这其实也是最近做大项目的一个感想吧，终于把我们组的项目结构理清了，不得不说，还是Java的那一套分模块看着清晰。
