微服务的理解和学习

  • 一、谈谈你对微服务的理解，微服务有哪些优缺点？
  • 二、SpringCloud和SpringCloudAlibaba都有哪些组件？都解決了什么问题？
  • 三、分布式事务如何处理？怎么保证事务一致性？
  • 四、怎么拆分微服务？怎样设计出高内聚、低耦合的微服务？有没有了解过DDD领域驱动设计？什么是中台？中台和微服务有什么关系？
  • 五、你的项目中是怎么保证微服务敏捷开发的？微服务的链路追踪、持续集成、AB发布要怎么做？



要了解组件的功能，对微服务的思考。

一、谈谈你对微服务的理解，微服务有哪些优缺点？

微服务（和DDD）是由Martin fowler大师提出的。微服务是一种架构风格，通过将大型的单体应用划分为比较小的服务单元，从而降低整个系统的复杂度。
注：解决系统复杂度的新方向是DDD。
优点：
1、服务部署更灵活：每个应用都可以是一个独立的项目，可以独立部署，不依赖于其他服务，耦合性降低。
2、技术更新灵活：在大型单体应用中，技术要进行更新，往往是非常困难的。而微服务可以根据业务特点，灵活选择技术栈。
3、应用的性能得到提高：大型单体应用中，往往启动就会成为一个很大的难关。而采用微服务之后，整个系统的性能是能够得到提高的。
4、更容易组合专门的团队：在单体应用时，团队成员往往需要对系统的各个部分都要有深入的了解，门槛是很高的。而采用微服务之后，可以给每个微服务组建专门的团队。
5、代码复用：很多底层服务可以以REST API的方式对外提供统一的服务，所有基础服务可以在整个微服务系统中通用。

缺点：
1、分布式部署之后，服务调用的复杂性提高了：网络问题、容错问题、负载问题、高并发问题。
2、分布式事务：尽量不要使用微服务事务。
3、测试的难度提升了：单体架构懂业务就可以了，微服务的还要懂微服务之间的拆分。
4、运维难度提升：单体架构只要维护一个环境，而到了微服务是很多个环境，并且运维方式还都不一样。所以对部署、监控、告警等要求就会变得非常困难。

二、SpringCloud和SpringCloudAlibaba都有哪些组件？都解決了什么问题？

SpringCloud：提供了构建微服务系统所需要的一组通用开发模式以及一系列快速实现这些开发模式的工具。

通常所说的SpringCloud是指Spring Cloud NetFlix，他和SpringCloudAlibaba都是Spring Cloud这一系列开发模式的具体

实现。

微服务key 微服务可以提高性能吗_微服务


SpringCloud：

  1. Eureka 服务注册发现 ：各个服务启动时，EurekaClient都会将服务注册到EurekaServer，并且EurekaClient还可以反过来从EurekaServer拉取注册表，从而知道其他服务在哪⾥
  2. Ribbon 负载均衡：服务间发起请求的时候，基于Ribbon做负载均衡，从一个服务的多台机器器中选择一台
  3. Feign 服务调用：基于Feign的动态代理理机制，根据注解和选择的机器器，拼接请求URL地址，发起请求
  4. Hystrix 服务熔断：发起请求是通过Hystrix的线程池来走的，不同的服务⾛不同的线程池，实现了不同服务调用的隔离，避免了服务雪崩的问题
  5. Zuul 服务路由：如果前端、移动端要调用后端系统，统一从Zuul网关进入，由Zuul网关转发请求给对应的服务
  6. Config 配置服务：基于git

SpringCloudAlibaba：
服务注册发现：Nacos
服务限流降级：Sentinel
分布配置中心：Nacos
服务网关：Gateway
服务之间调用：OpenFeign、Ribbon 基于Dubbo
链路追踪：Sleuth+Zipkin
网关：gateway
分布式事务：Seata
通信方式：http restful

三、分布式事务如何处理？怎么保证事务一致性？

误区：分布式事务=Seata
分布式事务：就是要将不同节点上的事务操作，提供操作原子性保证。同时成功或者同时失败。
分布式事务第一个要点就是要在原本没有直接关联的事务之间建立联系。

解决方案：

1、HTTP连接：最大努力通知。支付宝将每一步操作尽量通知给电商网站。还要加上事后补偿。

2、MQ：事务消息机制。

3、Redis：也可以定制出分布式事务机制。

微服务key 微服务可以提高性能吗_微服务_02


4、seata：是通过TC来在多个事务之间建立联系。

两阶段：AT XA 就在于要锁资源。

微服务key 微服务可以提高性能吗_微服务key_03

三阶段：ICC 在两阶段的基础上增加一个准备阶段。在准备阶段是不锁资源的。

微服务key 微服务可以提高性能吗_微服务key_04


SAGA模式：类似于熔断。业务自己实现正向操作和补偿操作的逻辑。不需要锁资源，先扣钱，如果需要回滚，把扣的钱补偿回去。

四、怎么拆分微服务？怎样设计出高内聚、低耦合的微服务？有没有了解过DDD领域驱动设计？什么是中台？中台和微服务有什么关系？

  1. 拆分微服务的时候，为了尽量保证微服务的稳定，会有一些基本的准则：
    1、微服务之间尽量不要有业务交叉。
    2、微服务之前只能通过接口进行服务调用，而不能绕过接口直接访问对方的数据。
    3、高内聚，低耦合。
  3. 怎样设计出高内聚、低耦合的微服务？
    高内聚低耦合，是一种从上而下指导微服务设计的方法。实现高内聚低耦合的工具主要有 同步的接口调用 和 异步的事件驱动两种方式。
    ①同步的接口调用：接口进行依赖；②异步的事件驱动：通过mq或者观察者模式。

    4. 微服务key 微服务可以提高性能吗_微服务key_05

  4. 什么是DDD？
    领域驱动设计
  5. 什么是中台？中台和微服务有什么关系？
    中台这个概念是由阿里在2015年提出"小前台，大中台”战略思想。
    superCell 《皇室战争》《部落冲突》
    所谓中台，就是将各个业务线中可以复用的一些功能抽取出来，剥离个性，提取共性，形成一些可复用的组件。 盒马鲜生、
    团购
    大体上，中台可以分为三类 业务中台、数据中台和技术中台。大数据杀熟-数据中台
    电商 收银中台 支付风控中台
    中台跟DDD结合：DDD会通过限界上下文将系统拆分成一个一个的领域，而这种限界上下文，天生就成了中台之间的逻辑
    屏障。
    DD在技术与资源调度方面都能够给中台建设提供不错的指导。
    DDD分为战略设计和战术设计。上层的战略设计能够很好的指导中台划分，下层的战术设计能够很好的指导微服务搭建。
    在目前阶段，DDD还大都处在小范围实验的阶段。

五、你的项目中是怎么保证微服务敏捷开发的？微服务的链路追踪、持续集成、AB发布要怎么做？

考虑微服务怎么落地？首先得有微服务的技术开发出一个微服务系统，然后得有一个好的方法论来提升系统的性能，并且把这些服务联系起来，接下来需要思考怎么把这些微服务落地到具体的部署上面。微服务面向开发运维一体化，开发的过程中，也要考虑测试和运维的工作内容。

敏捷开发：目的就是为了提高团队的交付效率，快速迭代，快速试错。
①在版本上面，每个月固定发布新版本，以分支的形式保存到代码仓库中，有很多功能还没到上线阶段，还在构思，可以先开发出来，等需要上线的时候可以快速上线。
②在管理方面，包括人员的快速入职，只需要了解当前所在微服务的业务内容，包括一些老带新的策略，快速了解系统。
③任务面板（待开发、开发中、已开发、测试中、已测试、测试完成的状态）、每天早上开一个10分钟的站立会议，每个人说一下昨天的工作和今天的任务。
④团队人员灵活流动，同时形成各个专家代表，对测试问题、运维问题、支付问题等有代表，让项目有问题时可以快速找到对应的负责人解决相应的问题。
⑤测试环境-生产环境-》开发测试环境SIT、集成测试环境、压测环境STR、预投产环境、生产环境PRD。
⑥文档优先（需求文档、开发设计方案文档、测试文案）。晨会、周会、需求拆分会。

链路追踪：
为什么需要链路跟踪？
微服务架构中，一个前端请求可能会调用到多个后端服务中的多个接口，当其中某个请求不可用时，最终会导致本次调用失败，此时需要我们能快速定位故障点，而我们又很难判断是由哪个后端服务引发的问题。 为了使得定位快速快，我们需要知道一个请求到底有哪些服务参与，参与顺序怎样，从而达到每个请求的步骤清晰可见，于是就有了分布式系统调用跟踪的诉求。
解决方案：
①基于日志。 形成全局事务1D，落地到日志文件。filebeat->logstash->Elasticsearch 形成大型报表。
②基于MQ，往往需要架构支持。把一些关键的消息发到mq上，经过流式计算形成一些可视化的结果。

持续集成：SpringBoot maven pom ->build -> 调用本地的shell脚本 ; Jenkins在git仓库上面做个钩子，当git有代码提交时，就发起编译，落地到对应的服务器上面，从而提高部署、测试速度。

AB发布：1、蓝绿发布、红黑发布， 老版本和新版本是同时存在的。等新版本稳定了，就把老版本升级到新版本。2、灰度发布、金丝雀发布。通过调整负载的方式来部署新版本。比如，原本用户的请求分布在十台服务器上面，我们通过调整，让请求访问三天新版本的，七台老版本的。