【微服务】走进微服务

r囧r小猫 2022-05-15 04:56 446阅读 0赞

# 微服务 #

介绍微服务时，我们首先理解什么是微服务，从两方面理解，什么是微，什么是服务，微，狭义来讲就是体积小、著名的“2pizza团队”很好的诠释了，单个服务的设计，所有参与人从设计、开发、测试、运维所有人加起来只需要两个披萨就够了。所谓服务，一定要区别与系统，服务一个或者一组相对较小且独立的功能单元，是用户可以感知的最小功能集。  
![这里写图片描述][70]

## 微服务本质 ##

*  独立部署、运行、升级
 *  有效拆分应用，让开发与部署更简单
 *  理念团队间应是inter-operate,not integrate（inter-operate，定义好系统边界和接口，一个团队内全栈，让团队自治，将跨系统的沟通成本降低）

## 微服务架构 ##

![这里写图片描述][70 1]

*  整套开发技术栈以SpringCloud为主，单个微服务模块以SpringMVC+SpringBoot/Spring+Mybatis组合开发。
 *  前端，H5+Bootstrap/Vue/Ionic等；
 *  负载层：前端访问通过Http或Https协议到达服务端的LB，可以F5做负载均衡，也可自行部署LVS+Keepalived等（前期量小可以直接用Nginx）；
 *  网关层：请求通过LB后，会到整个微服务体系的网关层Zuul（Gateway），内嵌Ribbon做客户端负载均衡，Hystrix做熔断降级等；
 *  服务注册：采用Eureka做服务治理，Zuul会从Eureka集群获取已发布的微服务访问地址，然后根据配置把请求代理到相应的微服务；
 *  docker容器：所有微服务模块都部署在Docker容器里，而且前后端的服务完全分开，各自独立部署后前端微服务调用后端微服务，后端微服务之间会相互调用；
 *  服务调用：微服务模块间调用采用标准的Http/Https+REST+JSON的方式，调用技术采用Feign+HttpClient+Ribbon+Hystrix；
 *  统一配置：每个微服务模块会跟Eureka集群、配置中心等进行交互，统一配置中心配置文件托管到GitHub，微服务获取配置是从统一配置中心，实际是从GitHub。
 *  第三方框架：每个微服务模块根据实现的需要，通常还需要使用一些第三方框架，比如常见的：缓存服务（Redis）、图片服务（FastDFS）、搜索服务（Solr）、安全管理（Shiro）等；
 *  Mysql数据库：可以按照微服务模块进行拆分，统一访问公共库或单独自己库，可以单独构建mysql集群或分库分表MyCat等

## 什么样的项目适合微服务？ ##

微服务要根据业务本身的独立性划分，如果业务比较底层，功能和功能间紧密配合，如果强拆，会带来不必要的麻烦，无法做到独立部署和运行，也就不适用做微服务了。  
能不能做微服务，取决于四个要素：

*  小：体积小，2 pizza团队
 *  独：独立部署和运行
 *  轻：轻量级通信，REST
 *  松：松耦合

确定使用微服务了，我们该如何拆分呢？

## 微服务拆分与设计 ##

### 拆分： ###

1、从单体式结构转向微服务架构中会持续碰到服务边界划分的问题：目前为止还没有服务边界划分的标准，只能根据不同的业务系统加以调节。  
2、拆分原则：一块业务不依赖或极少依赖其他服务，为超过2个的其他服务提供数据，就可以拆分成一个独立的服务模块。

### 设计： ###

基本原则有四：  
1、单一职责

*  每个微服务只需要实现自己的业务逻辑，其他不必考虑

2、服务自治

*  开发、测试、运维独立，DB独立，自己有一套完整的流程

3、轻量级通信

*  通信语言轻量，跨语言、跨平台，让每个微服务有足够独立性，不受技术的约束

4、接口明确

*  接口做到通用，灵活，避免由于某个微服务的接口变化导致其他微服务做调整

## 如何权衡微服务的利弊？ ##

凡事有利有弊，我们该如何取舍？既然微服务有那么多弊端，我们为什么还要用它，是否与我们的初衷相悖？  
两个字：平衡。  
凡事有利有弊，难道我们会因为有利就盲目选择去用，有弊就会狠心抛弃吗？不对，微服务可以给我们带来的利，带来的方便是其他结构无法取代的，尽管有弊端，但是我们可以尽量去弥补，可以采取一些措施，尽量变得更好。事物发展总是这样的规律，我们不能因为有弊端就止步不前，不去发展，不去创新。我用它，是因为没有比它更适合的了，所以凡事不能一概而论，否则将自己绕在利弊取舍间，将是自取灭亡。

## 微服务开发框架 ##

目前最常用的有四个：

*  Spring Cloud (非常流行)
 *  Dubbo
 *  Dropwizard
 *  Consul、etcd

**选Spring Cloud不选Dubbo原因：**  
![这里写图片描述][70 2]

## Spring Cloud和Spring Boot ##

**boot可以离开cloud，cloud离不开boot。**

*  Spring Boot：  
    
    
     *  关注微观
     *  简化spring应用和服务，简化配置文件，诸多开箱即用微服务功能，可以和spring cloud联合部署
 *  Spring Cloud：  
    
    
     *  关注宏观，服务治理框架
     *  微服务工具包，为开发者提供分布式系统的Config、Hystrix、Zuul、微代理、控制总线等开发工具包

这么多微服务，我们必须要考虑客户端如何访问这些服务呢？服务间如何通信？这么多服务，怎么查找？服务挂了怎么办？  
别急，小编下篇博客继续，欢迎你的来访！

感谢您的阅读！

[70]: /images/20220515/8ed804bc1b394762944134318555b0af.png
[70 1]: /images/20220515/9bec0bc21e9843d08c6cb24349addcb1.png
[70 2]: /images/20220515/891d207f74b14f6a99ce969a6cae726e.png