在开始之前，先声明一下我对微服务的态度：架构模式有很多种，微服务不是唯一的选择，也不是灵丹妙药。国内绝大多数中小企业在引入微服务时都是盲目追新，也可以看出做这种技术选型的工程师基础素质不足。“你必须足够高才能使用微服务”。微服务基础设施，尤其是容器技术、自动化部署、自动化测试不完善。微服务是没有用的，不会带来任何质的提升。微服务架构的关键不在于具体实现，而在于如何合理划分服务边界，组织结构是否匹配。不考虑研发团队的规模和构成，一味采用微服务是一种糟糕的技术选择。SpringBoot是Spring全家桶的上层包。它不是一个全新的技术，也不是一个值得被视为自身杀手的技术。SpringCloud中SpringCloudNetflix的组件已经在生产环境中经过验证，其他的建议慎重选择。一、什么是微服务微服务起源于2005年云计算博览会上PeterRodgers博士提出的Micro-Web-Service，其基本思想类似于Unix的流水线设计理念。2014年，MartinFowler和JamesLewis共同提出微服务的概念，将微服务架构风格定义为通过一组小服务开发单个应用程序的方法，每个服务运行在自己的进程中，并通过轻量级机制进行通信（HTTPAPI）。三个关键点是小型化、自动化和轻量级。与SOA相比，微服务可以看作是SOA的一个子集，它是一种轻量级的SOA，具有更细粒度的服务、独立的流程和数据分离，更注重敏捷、持续交付、DevOps和去中心化实践。其共同的架构原则：单一职责关注点分离：控制和逻辑分离模块化和分而治之的特点：服务组件化围绕业务能力的组织是产品而不是项目端点智能和哑管道：控制逻辑在最后，管道只是对全自动化部署语言和数据传输的去中心化控制面向失败的设计渐进式设计优缺点如下优缺点：模块边界强独立部署技术选择多样性缺点：分布式带来编程复杂度，远程调用放弃强一致性，实现最终一致性操作复杂度，需要成熟的运维团队或运维基础设施2.为什么使用微服务是否选择微服务，取决于系统的复杂度em你想设计。微服务是用来控制复杂系统的，下面介绍的是微服务本身的复杂性。其他分布式系统面临的问题，包括自动化部署、监控、容错、最终一致性等都需要解决。尽管已经有一些常用的解决方案，但仍然存在相当大的成本。生产力和复杂性之间的关系如图所示。可见，越是复杂的系统，微服务带来的好处就越大。另外，无论是单体应用还是微服务，都需要团队的技能能够驾驭。MartinFowler的观点之一是：除非管理单体应用的成本已经太复杂（大到难以修改和部署），否则不要考虑微服务。大多数应用应该选择单体架构，做好单体应用的模块化，而不是拆分成服务。因此，系统一开始就采用了单体架构，并做好了模块化工作。后来随着系统越来越复杂，模块/服务之间的界限越来越清晰，重构为微服务架构是一种合理的架构演进。小路。微服务可以考虑的四种情况：多人开发一个模块/项目，代码提交时经常发生冲突。这些模块是高度耦合的并且相互依赖。每个更改都需要涉及多个团队。单次发射要求太多，风险大。主辅业务耦合，横向扩展过程复杂。熔断器降级取决于if-else。微服务的三个阶段Microservice1.0：只使用注册发现，基于SpringCloud或Dubbo开发。微服务2.0：采用熔断、限流、降级等服务治理策略，配备完备的服务工具和平台。微服务3.0：ServiceMesh将服务治理作为一个通用组件，下沉到平台层去实现。应用层只关注业务逻辑，平台层可以根据业务监控自动调度调整参数，实现AIOps和智能调度。3.微服务架构前提条件快速环境提供能力：依托云计算和容器技术快速交付环境。基础监控能力：包括基础技术监控和业务监控。应用快速部署能力：要求部署流水线提供快速部署能力。Devops文化：需要具备良好的持续交付能力，包括全链路跟踪、快速环境提供和部署等，还需要快速响应能力（对问题和故障的快速响应），以及开发和运维之间的协同工作。此外，根据Conway'sLaw和InverseConway'sLaw（技术架构推动组织结构改善），组织结构也是一个关键因素。对应微服务架构，组织架构需要遵循以下原则：一个微服务由一个团队维护，团队成员最好是三人。单个团队的任务和发展是独立的，独立于其他因素。团队是全功能的、全栈的、自治的、扁平的和自我管理的。基础设施微服务的实现需要依赖很多底层基础设施，包括微服务的编译、集成、打包、部署、配置等。PaaS平台用于解决微服务从开发到运行的全生命周期管理。架构环境管理、容器资源隔离与互通、服务伸缩与漂移、服务升级与回滚、服务熔断与降级、服务注册与发现。最基本的基础设施进程间通信机制：微服务是独立的进程，需要确定它们之间的通信方式。服务发现+服务路由：提供服务注册中心，服务提供者和消费者通过服务发现获取服务信息调用服务，实现服务负载均衡。服务容错：在微服务架构中，由于服务数量众多，经常会出现一个服务挂掉，影响整个请求链路的服务。因此，需要服务容错。当服务调用失败时，可以快速处理错误或失败，包括熔断、回退、重试、流量控制和服务隔离等。分布式事务支持：由于业务拆分成服务，有时会跨服务事务，即分布式交易，无法避免。原则是尽量避免分布式事务。如果无法避免，可以使用消息系统或者CQRS和EventSourcing方案来实现最终一致性。如果需要强一致性，有两阶段提交、三阶段提交、TCC等分布式事务方案。提高对外服务对接和内部开发API网关的效率：负责外部系统的接入，负责跨部门的公共层面工作，包括安全、日志、权限控制、传输加密、请求转发、流量控制，ETC。典型的网关功能是对外暴露一个域名xx.com，根据一级目录进行反向路由xx.com/user和xx.com/trade。每一级目录，如user、trade，对应一个服务的域名。另外API网关还可以有服务编排的功能（不推荐）。接口框架：规范服务间通信的数据格式、解析包、自解释文档，便于服务使用者快速上手。提升测试和运维效率持续集成：这部分不是微服务特有的，对于之前的单体应用来说一般都是必须的。主要是指通过自动化手段对代码过程进行持续的编译、构建和自动化测试，以获得快速有效的质量反馈，从而保证代码的顺利交付。自动化测试包括代码层面的单元测试、单个系统的集成测试和系统间的接口测试。自动化部署：微服务架构，节点数可以是几百甚至上千，自动化部署可以提高部署的速度和频率，从而保证持续交付。包括版本管理、资源管理、部署操作、回滚操作等功能。至于微服务的部署方式，有蓝绿部署、滚动部署、金丝雀部署等。配置中心：运行时配置管理，解决动态修改配置并批量生效的问题。包括配置版本管理、配置项管理、节点管理、配置同步等。持续交付：包括持续集成、自动化部署等流程。目的是小步迭代，快速交付。进一步提升运维效率服务监控：微服务架构下节点数量众多，需要监控的机器、网络、进程、接口等数量大幅增加。需要一个强大的监控系统，可以提供实时的信息采集进行分析和实时分析。在警告上。包括监控服务请求次数、响应时间分布、最大/最小响应值、错误码分布等服务跟踪：跟踪一个请求的完整路径，包括请求发起时间、响应时间、响应码、请求参数、返回结果等信息，也称为全链接跟踪。通用服务监控可以和服务监控一起做，宏观信息通过服务跟踪呈现，单个服务/节点的微观信息通过服务监控呈现。目前服务跟踪的实现理论基本上是Google的Dapperpaper。服务安全：原则上内网之间的微服务调用应该可以互相访问和写入。一般不需要权限控制，但有时限于业务需求，对接口、数据等方面有安全控制需求。这部分可以以配置的形式存在于服务注册中心，与服务绑定，在请求时作为服务提供者受服务节点的安全策略控制。配置可以保存在配置中心，方便动态修改。在微服务数量较少的情况下，上述基础设施的优先级从上到下递减。否则，仅靠人工操作，投入产出比会很低。另外值得一提的是Docker容器技术。虽然这对微服务来说不是必需的，但容器技术的轻量、灵活、依赖应用、屏蔽环境差异等特性对于实现持续交付至关重要，即使对于传统的单体应用也是如此。带来交付效率的大幅提升。4.架构设计模式引入微服务后，传统的单体应用变成了一个一个的服务，以前应用直接提供接口供客户端访问的架构不再适用。在微服务架构下，针对不同设备的接口被用作BFF层（BackendForFrontend），也称为用户体验适配层，负责将微服务的数据转换为前端需要的数据进行聚合整理.服务之间的调用尽可能使用异步消息传递（允许延迟），从而形成面向用户体验的微服务架构设计模式。如下图所示：Client->APIGateway->BFF(BackendForFrontend)->DownstreamMicroservices后台采用微服务架构，微服务可以使用不同的编程语言和不同的存储机制。前台采用BFF模式，以适应不同的用户体验（如桌面浏览器、NativeApp、平板响应式Web）。BFF、APIOrchestrationLayer、EdgeServiceLayer、DeviceWrapperLayer是同一个概念。BFF不能太多，太多会造成代码逻辑冗余。网关所承担的功能，如Geoip、限流、安全认证等横截面功能，可以与BFF同层实现。虽然增加了BFF层的复杂度，但可以获得性能优势。5、服务拆分微服务架构的核心环节主要是服务的水平拆分。服务拆分是指将一个完整的业务系统解耦为服务。服务要求职责单一，相互之间无耦合关系，可独立开发和维护。服务拆分不是一蹴而就的，需要在发展过程中不断厘清边界。尽量推迟拆分服务，尤其是数据库，直到你完全解决它们。拆分方式如下：基于业务逻辑的拆分基于可扩展性的拆分基于可靠性的拆分基于性能的拆分其中，对于无法修改的遗留系统，采用扼杀者模式：在遗留系统之外添加新功能到做微服务，而不是直接修改原来的系统，逐步实现对旧系统的替换。拆分过程中需要遵循的规范如下：先少后多，先粗后细（粒度）服务可以垂直拆分到三层，有两个调用：Controller，combinedservice，和基础服务只在一个方向调用，串行调用禁止循环调用改为并行调用或异步接口。幂等接口数据定义严禁嵌入。标准化项目名透传，先拆分服务，确定服务粒度后再拆分数据库。6.微服务框架上面介绍了微服务架构的诸多基础设施。如果每个基础设施都需要自己开发，那将是一个非常庞大的开发工作。市场上已经有很多开源微服务框架可供选择。SpringBootSpringBoot用于简化新Spring应用程序的初始构建和开发过程。虽然它不是微服务框架，但其最初的设计本质上是微应用的底层框架，因此非常适合微服务基础设施的开发和微服务的应用开发。尤其对于Spring技术栈团队来说，基于SpringBoot开发微服务框架和应用更是自然而然的选择。Dubbo&&MotanDubbo阿里开源的服务治理框架。它出现在微服务概念兴起之前，堪称SOA框架的杰作。但它只包含了微服务基础设施的部分功能，如断路器、服务跟踪、网关等都没有实现。Motan是微博开源的一个类Dubbo的RPC框架，比Dubbo更轻量。服务发现：服务发布、订阅、通知高可用性策略：Failover、Failfast、资源隔离-负载均衡：LeastActiveConnection、ConsistentHash、RandomRequest、Polling等可扩展性：支持SPI扩展（服务提供者接口）其他：调用统计、访问日志等。SpringCloudSpringCloud是基于SpringBoot的微服务框架，也可以看作是一套微服务实现规范。基本涵盖了微服务基础设施的方方面面，包括配置管理、服务发现、断路器、智能路由、微代理、控制总线、全局锁、决策竞选、分布式会话、集群状态管理等。它基于Spring生态，社区支持非常好。但是它的很多组件都没有经过生产环境的验证，需要慎重选择。SpringCloudNetflix是SpringCloud的一个子项目，是Spring对NetflixOSS的集成实现。基于Netflix的大规模使用，已经广泛使用的组件包括：另外，另一个子项目SpringCloudAlibaba是阿里巴巴开源的基于SpringBoot的微服务框架，主要支持阿里云服务。Eureka：服务注册和服务发现Ribbon：弹性智能的进程间和服务通信机制，客户端负载均衡Hystrix：熔断器，提供运行时延迟和容错隔离Zuul：服务网关ServiceMesh以上微服务框架都是具有侵入性，服务过程需要修改代码。ServiceMesh是下一代微服务架构，最明显的特点就是无入侵。采用sidecar模型解决系统架构微服务化后的服务间通信和治理问题。如下图：目前主流的开源实现包括：受限于ServiceMesh带来的性能延迟的开销和sidecar带来的分发复杂度的增加，不适合大规模部署（大量微服务），异构复杂度（交互协议/开发语言种类多的微服务架构带来的好处会更大。Linkerd和Envoy：以sidecar为核心，关注如何做好proxy，完成一些通用的控制Istio和Conduit：目前最流行的ServiceMesh实现侧重于更强大的控制平面（sidecar称为数据平面）功能。前者是谷歌和IBM的合作，使用Envoy作为sidecar部分的实现，后者是Linkerd作者的作品，相比之下，Istio的背景比较庞大，d功能强大，但可用性和易用性一直不高，而Conduit相对简单，专注于功能。SofastackAntFinancial是一套开源的中间件，用于构建金融级的分布式架构。一套完整的分布式应用开发工具，包括微服务开发框架、RPC框架、服务注册中心、全链路跟踪、服务监控、ServiceMesh等，特别值得一提的是SOFAMesh。事实上，下一代微服务架构ServiceMesh的大规模落地，就是基于Istio的改进和扩展。应该是目前国内最成熟的开源ServiceMesh方案。另外需要提到的是Kubernetes（K8s），它本身提供了一些微服务特性支持（通过域名进行服务发现），没有对代码的侵入。但是服务调用和断路器需要自己实现。综上所述，目前公司技术团队的技术栈是Spring，现有服务的实现是基于Dubbo，所以选择了SpringCloudNetflix作为基础微服务框架，对于不成熟或者缺少组件的业界比较成熟.组件可以更换。API网关：Zuul服务注册中心：Dubbo配置中心：disconf服务监控&&全链路跟踪：CAT服务开发框架：SpringBoot日志监控、告警：ELK+Elasalert流控：Sentinel消息队列：Kafka
