blog微服务架构代码_轻易掌握微服务架构

什么是微服务

首先微服务并没有一个官方的定义，想要直接描述微服务相当困难，我们可以通过对比传统WEB应用，来理解什么是微服务。

传统的WEB应用核心分为业务逻辑、适配器以及API或通过UI访问的WEB界面。业务逻辑定义业务流程、业务规则以及领域实体。适配器包括数据库访问组件、消息组件以及访问接口等。一个打车软件的架构图如下：

尽管也是遵循模块化开发，但最终它们会打包并部署为单体式应用。例如Java应用程序会被打包成WAR，部署在Tomcat或者Jetty上。

这种单体应用比较适合于小项目，优点是：

• 开发简单直接，集中式管理基本不会重复开发功能都在本地，没有分布式的管理开销和调用开销

当然它的缺点也十分明显，特别对于互联网公司来说：

• 开发效率低：所有的开发在一个项目改代码，递交代码相互等待，代码冲突不断代码维护难：代码功能耦合在一起，新人不知道何从下手部署不灵活：构建时间长，任何小修改必须重新构建整个项目，这个过程往往很长稳定性不高：一个微不足道的小问题，可以导致整个应用挂掉扩展性不够：无法满足高并发情况下的业务需求

所以，现在主流的设计一般会采用微服务架构。其思路不是开发一个巨大的单体式应用，而是将应用分解为小的、互相连接的微服务。一个微服务完成某个特定功能，比如乘客管理和下单管理等。每个微服务都有自己的业务逻辑和适配器。一些微服务还会提供API接口给其他微服务和应用客户端使用。

比如，前面描述的系统可被分解为：

每个业务逻辑都被分解为一个微服务，微服务之间通过REST API通信。一些微服务也会向终端用户或客户端开发API接口。但通常情况下，这些客户端并不能直接访问后台微服务，而是通过API Gateway来传递请求。API Gateway一般负责服务路由、负载均衡、缓存、访问控制和鉴权等任务。

微服务架构的优点

微服务架构有很多重要的优点。首先，它解决了复杂性问题。它将单体应用分解为一组服务。虽然功能总量不变，但应用程序已被分解为可管理的模块或服务。这些服务定义了明确的RPC或消息驱动的API边界。微服务架构强化了应用模块化的水平，而这通过单体代码库很难实现。因此，微服务开发的速度要快很多，更容易理解和维护。

其次，这种体系结构使得每个服务都可以由专注于此服务的团队独立开发。只要符合服务API契约，开发人员可以自由选择开发技术。这就意味着开发人员可以采用新技术编写或重构服务，由于服务相对较小，所以这并不会对整体应用造成太大影响。

第三，微服务架构可以使每个微服务独立部署。开发人员无需协调对服务升级或更改的部署。这些更改可以在测试通过后立即部署。所以微服务架构也使得CI／CD成为可能。

最后，微服务架构使得每个服务都可独立扩展。我们只需定义满足服务部署要求的配置、容量、实例数量等约束条件即可。比如我们可以在EC2计算优化实例上部署CPU密集型服务，在EC2内存优化实例上部署内存数据库服务。

微服务架构的缺点和挑战

实际上并不存在silver bullets，微服务架构也会给我们带来新的问题和挑战。其中一个就和它的名字类似，微服务强调了服务大小，但实际上这并没有一个统一的标准。业务逻辑应该按照什么规则划分为微服务，这本身就是一个经验工程。有些开发者主张10-100行代码就应该建立一个微服务。虽然建立小型服务是微服务架构崇尚的，但要记住，微服务是达到目的的手段，而不是目标。微服务的目标是充分分解应用程序，以促进敏捷开发和持续集成部署。

微服务的另一个主要缺点是微服务的分布式特点带来的复杂性。开发人员需要基于RPC或者消息实现微服务之间的调用和通信，而这就使得服务之间的发现、服务调用链的跟踪和质量问题变得的相当棘手。

微服务的另一个挑战是分区的数据库体系和分布式事务。更新多个业务实体的业务交易相当普遍。这些类型的事务在单体应用中实现非常简单，因为单体应用往往只存在一个数据库。但在微服务架构下，不同服务可能拥有不同的数据库。CAP原理的约束，使得我们不得不放弃传统的强一致性，而转而追求最终一致性，这个对开发人员来说是一个挑战。

微服务架构对测试也带来了很大的挑战。传统的单体WEB应用只需测试单一的REST API即可，而对微服务进行测试，需要启动它依赖的所有其他服务。这种复杂性不可低估。

微服务的另一大挑战是跨多个服务的更改。比如在传统单体应用中，若有A、B、C三个服务需要更改，A依赖B，B依赖C。我们只需更改相应的模块，然后一次性部署即可。但是在微服务架构中，我们需要仔细规划和协调每个服务的变更部署。我们需要先更新C，然后更新B，最后更新A。

部署基于微服务的应用也要复杂得多。单体应用可以简单的部署在一组相同的服务器上，然后前端使用负载均衡即可。每个应用都有相同的基础服务地址，例如数据库和消息队列。而微服务由不同的大量服务构成。每种服务可能拥有自己的配置、应用实例数量以及基础服务地址。这里就需要不同的配置、部署、扩展和监控组件。此外，我们还需要服务发现机制，以便服务可以发现与其通信的其他服务的地址。因此，成功部署微服务应用需要开发人员有更好地部署策略和高度自动化的水平。

以上问题和挑战可大体概括为：

• API Gateway服务间调用服务发现服务容错服务部署数据调用

幸运的是，出现了很多微服务框架，可以解决以上问题。

雪崩效应

微服务化产品线，每一个服务专心于自己的业务逻辑，并对外提供相应的接口，看上去似乎很明了，其实还有很多的东西需要考虑，比如：服务的自动扩充，熔断和限流等，随着业务的扩展，服务的数量也会随之增多，逻辑会更加复杂，一个服务的某个逻辑需要依赖多个其他服务才能完成。一但一个依赖不能提供服务很可能会产生雪崩效应，最后导致整个服务不可访问。

微服务之间进行rpc或者http调用时，我们一般都会设置调用超时，失败重试等机制来确保服务的成功执行，看上去很美，如果不考虑服务的熔断和限流，就是雪崩的源头。

假设我们有两个访问量比较大的服务A和B，这两个服务分别依赖C和D,C和D服务都依赖E服务

A和B不断的调用C,D处理客户请求和返回需要的数据。当E服务不能供服务的时候，C和D的超时和重试机制会被执行

由于新的调用不断的产生，会导致C和D对E服务的调用大量的积压，产生大量的调用等待和重试调用，慢慢会耗尽C和D的资源比如内存或CPU，然后也down掉。

A和B服务会重复C和D的操作，资源耗尽，然后down掉，最终整个服务都不可访问。

常见的导致雪崩的情况有以下几种：

• 程序bug导致服务不可用，或者运行缓慢
• 缓存击穿，导致调用全部访问某服务，导致down掉
• 访问量的突然激增。
• 硬件问题，这感觉只能说是点背了⊙︿⊙。

虽然雪崩效应的产生千万条，保证服务的不挂机，和流畅运行是我们不可推卸的责任，对应雪崩效应还是有很多保护方案的。

服务的横向扩充

现在我们可以利用很多工具来保证服务不会挂掉，然后流量比较大的时候，可以横向扩充服务来保证业务的流畅。比如我们最常使用k8s，能保证服务的运行状态，也可以让服务自动的横向扩充。对于用户访问量的激增情况这样处理还是很不错的，但是，横向扩充也是有尽头的，如果在一定环境下E服务的响应时间过长，依然有可能导致雪崩效应的产生。

限流

限制客户端的调用来达到限流的做法是很常见的，比如，我们限制每秒最大处理200个请求，超过个数量直接拒绝请求。常见的算法如令牌桶算法

以一定的速度在桶里放令牌，当客户端请求服务的时候，要先从桶里得到令牌，才能被处理，如果没桶里的令牌用完了，则拒绝访问。

熔断

在客户端控制对依赖的访问，如果调用的依赖不可用时，则不再调用，直接返回错误，或者降级处理。开源的库比如hystrix-go，也是我接下来要写的源码分析的一个库。很好的实现了熔断和降级的功能。他的主要思想是，设置一些阀值，比如，最大并发数，错误率百分比，熔断尝试恢复时间等。能过这些阀值来转换熔断器的状态：

• 关闭状态，允许调用依赖
• 打开状态，不允许调用依赖，直接返回错误，或者调用fallback
• 半开状态，根据熔断尝试恢复时间来开启，允许调用依赖，如果调用成功则关闭失败则继续打开

感谢您耐心看完的文章

在这里给大家推荐一个 Java技术交流群：710373545， 里面会分享一些资深架构师录制的视频资料：有Spring，MyBatis，Netty源码分析，高并发、高性能、分布式、微服务架构的原理，JVM性能优化、分布式架构等这些成为架构师必备的知识体系。还能领取免费的学习资源，目前受益良多！