微服务Dubbo项目学习---day01---

1、关于微服务的基本概念

微服务就是把我们的业务拆分成微服务，因为单体的业务不方便我们去维护和开发。现在的项目都越来越大，如果后期需要加内存、加一些业务进去就会很麻烦。所以我们把一个大的项目拆分为小型业务，最后用Dubbo等让小型业务进行通信。

最基本的两个概念就是

provider：服务提供者，提供服务的实现

consumer：服务调用者，调用provider提供的服务实现。

注意：同一个服务可能即是provider又是consumer

2、Srping版Dubbo集成中文地址：https://dubbo.gitbooks.io/dubbo-user-book/content/preface/background.html

SpringBoot版本Dubbo集成中文地址：https:///alibaba/dubbo-spring-boot-starter/blob/master/README_zh.md

可以根据官方在GitHub上面的中文文档，快速搭建一个直连提供者的微服务测试项目。

不难看出这种直连提供者有他的弊端：

消费者知道服务提供者的地址，直接进行连接

该方式一般只在测试环境中使用

直接连接提供者限制了分布式的易拓展性

3、我们在实际开发中还需要引入三个概念

registry：服务注册与发现的注册中心，通常用zookeeper

monitor：统计服务的调用次数和调用时间的监控中心

container：服务运行容器

4、API网关的常见作用：

身份验证和安全

审查和监测

动态路由 cloud必须要做

压力测试  阶梯性测试

负载均衡

静态相应处理

API 网关并不是微服务场景中必须的组件，如下图，不管有没有 API 网关，后端微服务都可以通过 API 很好地支持客户端的访问。

假设你正在开发一个电商网站，那么这里会涉及到很多后端的微服务，比如会员、商品、推荐服务等等。

那么这里就会遇到一个问题，APP/Browser怎么去访问这些后端的服务? 如果业务比较简单的话，可以给每个业务都分配一个独立的域名(​​https://​​)，但这种方式会有几个问题:

• 每个业务都会需要鉴权、限流、权限校验等逻辑，如果每个业务都各自为战，自己造轮子实现一遍，会很蛋疼，完全可以抽出来，放到一个统一的地方去做。
• 如果业务量比较简单的话，这种方式前期不会有什么问题，但随着业务越来越复杂，比如淘宝、亚马逊打开一个页面可能会涉及到数百个微服务协同工作，如果每一个微服务都分配一个域名的话，一方面客户端代码会很难维护，涉及到数百个域名，另一方面是连接数的瓶颈，想象一下你打开一个APP，通过抓包发现涉及到了数百个远程调用，这在移动端下会显得非常低效。
• 每上线一个新的服务，都需要运维参与，申请域名、配置Nginx等，当上线、下线服务器时，同样也需要运维参与，另外采用域名这种方式，对于环境的隔离也不太友好，调用者需要自己根据域名自己进行判断。
• 另外还有一个问题，后端每个微服务可能是由不同语言编写的、采用了不同的协议，比如HTTP、Dubbo、GRPC等，但是你不可能要求客户端去适配这么多种协议，这是一项非常有挑战的工作，项目会变的非常复杂且很难维护。
• 后期如果需要对微服务进行重构的话，也会变的非常麻烦，需要客户端配合你一起进行改造，比如商品服务，随着业务变的越来越复杂，后期需要进行拆分成多个微服务，这个时候对外提供的服务也需要拆分成多个，同时需要客户端配合你进行改造，非常蛋疼。