/MicroService

微服务

微服务架构设计的首要任务就是合理划分微服务，即围绕业务功能创建微服务项目。在划分微服务时，有关微服务粗细粒度的考量，建议在平台创建的初始阶段使用粗粒度的方法，按业务功能进行划分。随着业务的发展及其运营的情况，再依据发展规模考虑是否继续细分。下面，我们将使用水平划分法和垂直划分法两种方法相结合的方式创建微服务

一方面在水平方向上：

根据业务功能划分微服务，并把这次划分所创建的微服务称为REST API微服务。REST API微服务负责业务功能的行为设计，主要完成数据管理方面的工作，并通过使用REST协议，对外提供接口服务。

另一方面在垂直方向上：

再以REST API微服务为基础，实现前后端分离设计，创建Web UI微服务。Web UI微服务不直接访问数据，它只专注于人机交互界面的设计，它的数据存取将通过调用REST API微服务来完成。这样，经过两次微服务划分，我们就可以创建出REST API和Web UI两种类型的微服务。也就是说，我们只要使用两种类型的微服务，就可以构建一个复杂的业务系统。

使用REST API和Web UI微服务，结合高性能和高并发的设计，再通过微服务的多副本发布，就可以构建一个能适应任何规模访问的、多维的、稳定牢固的网格结构，并且这个网格结构还具有自由伸缩的特性，可以根据业务的发展规模进行扩充或者缩编，这样就可以快速地搭建一个可持续扩展的系统平台

MicroService 面试

一个微服务的例子

image

15种微服务架构框架汇总

Top 10 Microservices frameworks for 2020

基于SpringCloud微服务系统设计,5万字总结！

微服务的设计模式

SpringBoot+CQRS微服务设计模式教程

一张图看懂微服务架构路线

在线书籍

微服务例子

Service Mesh微服务 微服务之间的几种调用方式哪种最佳？ 如何将微服务部署在kubernetes集群之上

目录

1 微服务架构设计---微服务的关注点在能力分治，将同类型的能力聚集在一个应用中，做到功能解耦，分别演化。这里涉及到两个点：微服务内部组件间如何调用 & 微服务整体如何对外提供服务。成熟方案是通过微服务框架（如SpringCloud）的功能组件完成，如前者属于服务治理和发现（Eureka），后者通过网关（gateway）

3 微服务架构方案

* [1 基于Spring Cloud的微服务架构方案    ](https://icyfenix.cn/exploration/projects/microservice_arch_springcloud.html)
* [2 基于Kubernetes的微服务架构方案 ](https://icyfenix.cn/exploration/projects/microservice_arch_kubernetes.html)
* [3 基于服务网格：Istio的微服务架构方案 ](https://icyfenix.cn/exploration/projects/servicemesh_arch_istio.html)
* [4 基于无服务：AWS Lambda的微服务架构方案 ](https://icyfenix.cn/exploration/projects/serverless_arch.html)
  • 后微服务时代---从软件层面独力应对微服务架构问题，发展到软、硬一体，合力应对架构问题的时代，此即为“后微服务时代”
    • 伸缩扩展对应的硬件解决方案

微服务架构的关键问题

微服务外部通信的架构方案

客户端可以向micro service发起RESTful HTTP请求，但是会有这种情况发生：客户端为了完成一个业务逻辑，需要发起多个HTTP请求，从而造成系统的吞吐率下降，再加上无线网络的延迟高，会严重影响客户端的用户体验，为了解决这个问题，一般会在服务器集群前面再加一个角色：API gateway，由它负责与客户度对接，并将客户端的请求转化成对内部服务的一系列调用。这样做还有个好处是，服务升级不会影响到客户端，只需要修改API gateway即可

1 API REST-based微服务架构方案实现方式

适合网站提供小规模的，自包含的服务。很多互联网网站都提供这样的服务，比如OAuth2服务

api-rest-based

2 applicaiton REST-based微服务架构方案实现方式

不同于上面的架构，客户端看到的是web界面或者富客户端程序，而不是调用API。UI层独立发布，可以访问服务组件

application-rest-base

3 中心化的消息微服务架构方案实现方式

它类似前面的模式，但是使用一个轻量级的消息broker取代RESTful的服务调用。这个轻量级的broker不会执行服务的编排，传输和路由，这和SOA不同，不要把它看作SOA的简化版

image

微服务内部通信的架构方案

内部服务之间的通信方式有两种：基于HTTP协议的同步机制（REST、RPC）；基于消息队列的异步消息处理机制（AMQP-based message broker）

1 基于HTTP协议的同步机制

2 基于消息队列的异步消息处理机制

微服务架构解决方案：

SpringCloud，是一套生态，就是解决以上分布架构的4个问题, 想使用SpringCloud，必须掌握SpringBoot，因为SpringCloud是基于SpringBoot；

 1. Spring Cloud Netflix，出来了一套解决方案:
 
    Api网关，zuul组件
    Feign--->HttpClient--->HTTP的通信方式，同步并阻塞
    服务注册与发现，Eureka
    熔断机制，Hystrix

    2018年年底，Netflix宣布无限期停止维护。生态不再维护，就会脱节。

2. Apache Dubbo zookeeper，第二套解决系统
    Api：没有！要么找第三方插件，要么自己实现
    Dubbo是一个高性能的基于Java实现的，RPC通信框架！
    服务注册与发现，zookeeper：动物园管理者（Hadoop，Hive）
    没有：借助了Hystrix

    不完善，Dubbo

3. SpringCloud Alibaba 一站式解决方案

当前各大IT公司用的微服务架构有那些？

     阿里：dubbo+HFS

     京东：JFS

     新浪：Motan

     当当网：DubboX

Dubbo 和 SpringCloud对比:

最大区别：Spring Cloud 抛弃了Dubbo的RPC通信，采用的是基于HTTP的REST方式

item Dubbo Spring Cloud
服务注册中心 Zookeeper Spring Cloud Netfilx Eureka
服务调用方式 RPC REST API
服务监控 Dubbo-monitor Spring Boot Admin
断路器 不完善 Spring Cloud Netfilx Hystrix
服务网关 无 Spring Cloud Netfilx Zuul
分布式配置 无 Spring Cloud Config
服务跟踪 无 Spring Cloud Sleuth
消息总栈 无 Spring Cloud Bus
数据流 无 Spring Cloud Stream
批量任务 无 Spring Cloud Task
Java架构：一文读懂微服务架构的重构策略 微服务架构经验和教训
阿里架构师教你：如何快速搭建一个微服务架构 耦合到底意味着什么呢
云原生应用之路——从Kubernetes到Cloud Native 如何基于 Spring Cloud Alibaba 构建微服务体系
ChaosBlade x SkyWalking 微服务高可用实践 微服务框架：如果不用Spring Boot，还可以选择谁
【项目实战】微服务多租户系统后台管理系统---基于SpringBoot2.x、SpringCloud和SpringCloudAlibaba并采用前后端分离的企业级微服务多租户系统架构
手摸手教你从开发到部署(CI/CD)GO微服务系列

微服务架构深度解析与最佳实践

微服务例子程序

最全面微服务教程：SpringBoot + DDD + Apache Kafka实现最终一致性

微服务理论主题

微服务技术栈有那些

微服务技术条目 落地技术
服务开发 SpringBoot、Spring、SpringMVC等
服务配置与管理 Netfix公司的Archaius、阿里的Diamond等
服务注册与发现 Eureka、Consul、Zookeeper等
服务调用 Rest、PRC、gRPC
服务熔断器 Hystrix、Envoy等
负载均衡 Ribbon、Nginx等
服务接口调用(客户端调用服务的简化工具) Fegin等
消息队列 Kafka、RabbitMQ、ActiveMQ等
服务配置中心管理 SpringCloudConfig、Chef等
服务路由(API网关) Zuul等
服务监控 Zabbix、Nagios、Metrics、Specatator等
全链路追踪 Zipkin、Brave、Dapper等
数据流操作开发包 SpringCloud Stream(封装与Redis，Rabbit，Kafka等发送接收消息)
时间消息总栈 SpringCloud Bus
服务部署 Docker、OpenStack、Kubernetes等
--- ---

微服务架构设计模式主题

微服务开发框架主题

  • 微服务网关
  • 微服务监控
    • Nagios
  • 微服务通信
    • RPC
    • REST
    • HAL
    • 消息队列
    • 后台任务处理系统
  • 微服务配置
  • 微服务日志
    • Splunk
  • 微服务测试
    • 微服务的测试策略
    • 微服务的单元测试
    • 微服务的的集成测试
    • 基于消费者驱动的契约测试
    • 微服务的组件测试
    • 微服务的端到端测试

微服务持续集成 交付 部署主题

微服务运维平台主题

单体应⽤和微服务各是什麽？

单体应⽤:

早些年，各⼤互联⽹公司的应⽤技术栈⼤致可分为LAMP（Linux + Apache + MySQL + PHP）和MVC（Spring +iBatis/Hibernate + Tomcat）两⼤流派。
⽆论是LAMP还是MVC，都是为单体应⽤架构设计的，其优点是学习成本低，开发上⼿快，测试、部署、运维也⽐较⽅便，甚⾄⼀个⼈就可以完成⼀个⽹站的开发
与部署。以MVC架构为例，业务通常是通过部署⼀个WAR包到Tomcat中，然后启动Tomcat，监听某个端⼝即可对外提供服务

微服务:

微服务就是将庞杂臃肿的单体应⽤拆分成细粒度的服务，独⽴部署，并交给各个中⼩团队来负责开发、测试、上线和运维整个⽣命周期

什么是服务化

服务化就是把传统的单机应⽤中通过JAR包依赖产⽣的本地⽅法调⽤，改造成通过RPC接⼝产⽣的远程⽅法调⽤

什么时候进⾏服务化拆分

项⽬第⼀阶段的主要⽬标是快速开发和验证想法，证明产品思路是否可⾏。这个阶段功能设计⼀般不会太复杂，开发采取快速迭代的⽅式，架构也不适合过度设计。
所以将所有功能打包部署在⼀起，集中地进⾏开发、测试和运维，对于项⽬起步阶段，是最⾼效也是最节省成本的⽅式。当可⾏性验证通过，功能进⼀步迭代，就
可以加⼊越来越多的新特性。

产品上线后，经过⼀段时间的运营，⽤户开始逐步增多，可⾏性验证通过，下⼀阶段就需要进⼀步增加更多的新特性来吸引更多的⽬标⽤户.⼀般情况下，这个时候
就需要⼤规模地扩张开发⼈员，以⽀撑多个功能的开发。如果这个时候继续采⽤单体应⽤架构，多个功能模块混杂在⼀起开发、测试和部署的话，就会导致不同功
能之间相互影响，⼀次打包部署需要所有的功能都测试OK才能上线,不仅如此，多个功能模块混部在⼀起，对线上服务的稳定性也是个巨⼤的挑战,⼀旦单体应⽤同
时进⾏开发的⼈员超过10⼈，就会遇到上⾯的问题，这个时候就该考虑进⾏服务化拆分了。

服务化拆分的前置条件

从单体应⽤迁移到微服务架构时必将⾯临也必须解决的问题

服务如何定义：

对于单体应⽤来说，不同功能模块之前相互交互时，通常是以类库的⽅式来提供各个模块的功能。对于微服务来说，每个服务都运⾏在各⾃的进程之中，
应该以何种形式向外界传达⾃⼰的信息呢？答案就是接⼝，⽆论采⽤哪种通讯协议，是HTTP还是RPC，服务之间的调⽤都通过接⼝描述来约定，约定内容包括接
⼝名、接⼝参数以及接⼝返回值。

服务如何发布和订阅：
单体应⽤由于部署在同⼀个WAR包⾥，接⼝之间的调⽤属于进程内的调⽤。⽽拆分为微服务独⽴部署后，服务提供者该如何对外暴露⾃⼰的地址，服务调⽤者该如
何查询所需要调⽤的服务的地址呢？这个时候你就需要⼀个类似登记处的地⽅，能够记录每个服务提供者的地址以供服务调⽤者查询，在微服务架构⾥，这个地⽅
就是注册中⼼

服务如何监控：
通常对于⼀个服务，我们最关⼼的是QPS（调⽤量）、AvgTime（平均耗时）以及P999（99.9%的请求性能在多少毫秒以内）这些指标。这时候你就需要⼀种通⽤的
监控⽅案，能够覆盖业务埋点、数据收集、数据处理，最后到数据展示的全链路功能

服务如何治理：
可以想象，拆分为微服务架构后，服务的数量变多了，依赖关系也变复杂了。⽐如⼀个服务的性能有问题时，依赖的服务都势必会受到影响。可以设定⼀个调⽤性
能阈值，如果⼀段时间内⼀直超过这个值，那么依赖服务的调⽤可以直接返回，这就是熔断，也是服务治理最常⽤的⼿段之⼀。

故障如何定位：
在单体应⽤拆分为微服务之后，⼀次⽤户调⽤可能依赖多个服务，每个服务⼜部署在不同的节点上，如果⽤户调⽤出现问题，你需要有⼀种解决⽅案能够将⼀次
⽤户请求进⾏标记，并在多个依赖的服务系统中继续传递，以便串联所有路径，从⽽进⾏故障定位。

服务化拆分的两种姿势

那么服务化拆分具体该如何实施呢？⼀个最有效的⼿段就是将不同的功能模块服务化，独⽴部署和运维

纵向拆分：

是从业务维度进⾏拆分。标准是按照业务的关联程度来决定，关联⽐较密切的业务适合拆分为⼀个微服务，⽽功能相对⽐较独⽴的业务适合单独拆分为⼀个微服务

横向拆分：

是从公共且独⽴功能维度拆分。标准是按照是否有公共的被多个其他服务调⽤，且依赖的资源独⽴不与其他业务耦合。

前期，可以稍微粗粒度⼀些。先进⾏纵向拆分，把基础功能（⽤户系统）独⽴部署以维护。其它业务功能关联不紧密的可以独⽴部署，可以看这些业务在公司发展
⽅向的重要性后⾯，可以看清哪些功能是其他业务系统⼀定要调⽤的，同时，⾃身系统内也有其他繁杂的功能，那么可以进⾏横向切分，把被频繁调⽤的服务抽象
并独⽴部署

⽆论是纵向拆分还是横向拆分，都是将单体应⽤庞杂的功能进⾏拆分，抽离成单独的服务部署。实际业务中这两种拆分⽅式⼀般是相互结合使⽤的，如果业务⽐较
多分散，适合做纵向拆分。如果多个业务之间有公共模块耦合，适合把公共模块拆分出来，适合做横向拆分

引⼊微服务架构需要解决的问题

服务化拆分后会带来的分布式服务事务的⼀致性问题，分布式数据⼀致性问题,，拆微服务势必会提⾼运维、问题追踪、分布式事务等复杂度

所以微服务整个技术栈都要考虑进去, 微服务只能解决单体膨胀后的痛，但也会带来架构复杂性

正常的服务调⽤的流程

⾸先服务提供者（就是提供服务的⼀⽅）按照⼀定格式的服务描述，向注册中⼼注册服务，声明⾃⼰能够提供哪些服务以及服务的地址是什么，完成服务发布。

接下来服务消费者（就是调⽤服务的⼀⽅）请求注册中⼼，查询所需要调⽤服务的地址，然后以约定的通信协议向服务提供者发起请求，得到请求结果后再按照约
定的协议解析结果。

⽽且在服务的调⽤过程中，服务的请求耗时、调⽤量以及成功率等指标都会被记录下来⽤作监控，调⽤经过的链路信息会被记录下来，⽤于故障定位和问题追踪。
在这期间，如果调⽤失败，可以通过重试等服务治理⼿段来保证成功率。

微服务视频

有用的参考