开启掘金成长之旅！这是我参与「掘金日新计划 · 12 月更文挑战」的第19天，点击查看活动详情
前言
在平时学习中，我们有时候会提到微服务，分布式等，那么什么是微服务呢？这时候百度的作用就提醒了
根据定义，我们可以get一个新词语————云原生，当然这个不是我们重点，重点是：微服务是一种架构方法，在单个应用中包含众多松散耦合而且可单独部署的小型组件或服务。
微服务架构通俗点说就是对原来庞大的项目进行拆分，每一个拆分后的模块独立形成一个新的项目（即服务），拆分后的服务和服务之间可按照一定方式（分布式）进行通信的架构。微服务拆分如下图所示 ：
微服务架构优点
项目复杂度降低：微服务通过拆分巨大的单体式应用，从而解决了单体式架构中的复杂性问题。
单体式架构介绍
单体式架构是将项目中所有的源码都放置在一个总项目中进行开发、部署和维护。项目可以分为多个模块，但多个模块的源码均属于一个项目，不同模块的开发者共同维护一份项目源码。
团队界限明确：微服务架构模式的每个服务都可以由专门的开发团队来完成
扩展灵活：微服务架构模式使得每个服务可以独立扩展。你可以根据每个服务的特点来部署满足需求的规模，也可以使用更适合于服务需求的硬件资源。
为啥会出现微服务
我们最先想到，肯定是以前的架构不能满足现在要求，那现在什么要求？
| 比较项 | 传统软件行业 | 互联网软件行业 |
|---|---|---|
| 用户群体 | 企业内部用户 | 互联网线上用户 |
| 用户量 | 小 | 庞大 |
| 并发考虑 | 少/几乎不用考虑 | 必须考虑 |
| 数据量 | 小 | 海量数据 |
| 架构方式 | 单体式架构 | 分布式微服务架构 |
| 部署 | 单个服务器 | 集群服务器 |
| 项目代码量 | 少 | 多而复杂 |
| 运维复杂度 | 低 | 高 |
从上面这些区别可以看出，面对如今用户量庞大的互联网行业，传统的单体式架构并不能满足如今互联网场景下的高并发需求了，所以如今互联网下的软件架构基本都是分布式微服务架构。
通过学习计算机网络，我们知道，通信最常见的是http模式
微服务架构给各个单服务之间进行通信提供了两种常用的方式：
- 一种是基于 HTTP 的 RESTful 风格的远程服务通信。
REST，是一组架构约束条件和设计原则。在微服务中，项目之间可以采用 RESTful 风格的 HTTP 方式互相调用。常用的微服务框架 Spring Cloud 及 Dubbox 均支持 RESTful 的调用方式。
- 一种是基于 RPC 的远程服务通信。
RPC，即远程过程调用。简单点说，就是可以在一个项目中像调用本地服务一样去调用其他项目的服务。常见的微服务框架 Dubbo 以及升级版的 Dubbox 均支持 RPC 的调用方式。
我们通常把微服务架构中调用服务的一方称为 Consumer（消费者） ，被调用的一方称为 Provider（提供者）
开发中常用的两种微服务框架：Dubbo/Dubbox、Spring Cloud。
Dubbo使用查看微服务框架 Dubbo简单学习 - 掘金 (juejin.cn)
spring cloud看上去和spring，springboot类似，其实Spring Cloud 是基于 Spring Boot 的一整套实现微服务的框架，Spring Boot 专注于快速、方便集成的单个微服务个体，而 Spring Cloud 关注全局的服务治理框架。
微服务架构设计原则
- 围绕业务切分：在决定将该项目拆分成多少个子项目时，需要按照对应业务进行拆分，避免业务过多交叉，接口实现复杂。
- 单一职责：在服务设计上，每一个服务职责尽可能单一。这样可以保证服务的模块化协作，即多个服务可以互相搭配完成一个整体功能。
- 谁创建，谁负责：由对应的项目组负责对应项目的创建和维护。一般微服务项目由其开发团队，直接对项目的开发、维护、部署进行负责，这样可以减少沟通成本
