技术干货分享：微服务浅谈服务治理的演变过程(2)

dubbo服务治理优势

• 注册中心只负责注册查找，不负责请求转发，压力小
• 注册中心宕机影响消费者，消费者本地缓存服务地址列表
• 注册中心对等集群，宕掉一台自动切换到另外 一台
• 服务提供者无状态，可动态部署，注册中心负责推送
• 统计无压力，本地内存中累计次数，每分钟发送注册中心
• 消费者调用服务者，自动软负载均衡
• 通过服务中心可追踪依赖关系
• 监控中心为扩容和降级提供依据
• 可启用acl机制进行鉴权
• 与Spring整合，接入简单松耦合
• 多种序列化协议支持

dubbo的不足

• 消费者仍需要依赖配置中心
• 消费者仍需要依赖jar包配置provider
• 提供者文档管理功能缺失
• 无统一入口
• 不支持OAuth2.0
• 内部鉴权不方便管理
• 无外部应用鉴权
• 接口基本裸奔，无法直接对外暴露服务
• IT治理不方便

微服务

现在很多人都在谈微服务，那么到底什么是微服务呢?这里谈谈我对微服务的理解。

微服务有两个核心：

• 微：服务的粒度要细，即服务要细化到API
• 服务：提供好服务，要让用户感到好用(要做到这一点很不容易)

微服务(Microservices)是一种架构风格，一个大型复杂软件应用由一个或多个微服务组成。系统中的各个微服务可被独立部署，各个微服务之间是松耦合的。每个微服务仅关注于完成一件任务并很好地完成该任务。在所有情况下，每个任务代表着一个小的业务能力。

微服务架构 ≈ 模块化开发 + 分布式计算

从上面这幅图看出，微服务特别简单(好的架构就应该简单)，我们把服务再拆分成一个个API，API是一个完整的功能。然后我们把API扔到一个“云上”，然后用户就可以到“云上”获取所有API的服务，这个“云”保证能提供好的服务。

我们可以看到，有了微服务之后，服务对用户来说变得特别简单，而且上面dubbo的不足之处在微服务这里都解决了。使用者不再需要依赖任何jar包，不再需要去注册中心查找服务，不再去做鉴权处理，不用担心服务挂掉，不用担心不会使用服务，所有的问题这个“云”都解决了。这也是微服务的核心之一，提供好服务。

说到这里，大家就应该大体知道该怎么做微服务了，图中的“云”是关键。下面我们就慢慢拨开这朵云。

微服务的实现

微服务的关键是服务网关，所以，上面提到的“云”就是服务网关。要做微服务，我们先定义一下微服务需要具备的特点。

常见的微服务组件及概念：

• 服务注册 ：服务提供方将自己调用地址注册到服务注册中心，让服务调用方能够方便地找到自己。
• 服务发现 ：服务调用方从服务注册中心找到自己需要调用的服务的地址。
• 负载均衡 ：服务提供方一般以多实例的形式提供服务，负载均衡功能能够让服务调用方连接到合适的服务节点。并且，节点选择的工作对服务调用方来说是透明的。
• 服务网关 ：服务网关是服务调用的唯一入口，可以在这个组件是实现用户鉴权、动态路由、灰度发布、A/B 测试、负载限流等功能。
• 配置中心 ：将本地化的配置信息(properties, xml, yaml 等)注册到配置中心，实现程序包在开发、测试、生产环境的无差别性，方便程序包的迁移。
• API 管理 ：以方便的形式编写及更新 API 文档，并以方便的形式供调用者查看和测试。
• 集成框架 ：微服务组件都以职责单一的程序包对外提供服务，集成框架以配置的形式将所有微服务组件(特别是管理端组件)集成到统一的界面框架下，让用户能够在统一的界面中使用系统。
• 分布式事务 ：对于重要的业务，需要通过分布式事务技术(TCC、高可用消息服务、最大努力通知)保证数据的一致性。
• 调用链 ：记录完成一个业务逻辑时调用到的微服务，并将这种串行或并行的调用关系展示出来。在系统出错时，可以方便地找到出错点。
• 支撑平台 ：系统微服务化后，系统变得更加碎片化，系统的部署、运维、监控等都比单体架构更加复杂，那么，就需要将大部分的工作自动化。现在，可以通过 Docker 等工具来中和这些微服务架构带来的弊端。 例如持续集成、蓝绿发布、健康检查、性能健康等等。严重点，以我们两年的实践经验，可以这么说，如果没有合适的支撑平台或工具，就不要使用微服务架构。

微服务架构的优点：

• 降低系统复杂度 ：每个服务都比较简单，只关注于一个业务功能。
• 松耦合 ：微服务架构方式是松耦合的，每个微服务可由不同团队独立开发，互不影响。
• 跨语言 ：只要符合服务 API 契约，开发人员可以自由选择开发技术。这就意味着开发人员可以采用新技术编写或重构服务，由于服务相对较小，所以这并不会对整体应用造成太大影响。
• 独立部署 ：微服务架构可以使每个微服务独立部署。开发人员无需协调对服务升级或更改的部署。这些更改可以在测试通过后立即部署。所以微服务架构也使得 CI/CD 成为可能。
• Docker 容器 ：和 Docker 容器结合的更好。
• DDD 领域驱动设计 ：和 DDD 的概念契合，结合开发会更好。

微服务架构的缺点：

• 微服务强调了服务大小，但实际上这并没有一个统一的标准 ：业务逻辑应该按照什么规则划分为微服务，这本身就是一个经验工程。有些开发者主张 10-100 行代码就应该建立一个微服务。虽然建立小型服务是微服务架构崇尚的，但要记住，微服务是达到目的的手段，而不是目标。微服务的目标是充分分解应用程序，以促进敏捷开发和持续集成部署。
• 微服务的分布式特点带来的复杂性 ：开发人员需要基于 RPC 或者消息实现微服务之间的调用和通信，而这就使得服务之间的发现、服务调用链的跟踪和质量问题变得的相当棘手。
• 分区的数据库体系和分布式事务 ：更新多个业务实体的业务交易相当普遍，不同服务可能拥有不同的数据库。CAP 原理的约束，使得我们不得不放弃传统的强一致性，而转而追求最终一致性，这个对开发人员来说是一个挑战。
• 测试挑战 ：传统的单体WEB应用只需测试单一的 REST API 即可，而对微服务进行测试，需要启动它依赖的所有其他服务。这种复杂性不可低估。
• 跨多个服务的更改 ：比如在传统单体应用中，若有 A、B、C 三个服务需要更改，A 依赖 B，B 依赖 C。我们只需更改相应的模块，然后一次性部署即可。但是在微服务架构中，我们需要仔细规划和协调每个服务的变更部署。我们需要先更新 C，然后更新 B，最后更新 A。
• 部署复杂 ：微服务由不同的大量服务构成。每种服务可能拥有自己的配置、应用实例数量以及基础服务地址。这里就需要不同的配置、部署、扩展和监控组件。此外，我们还需要服务发现机制，以便服务可以发现与其通信的其他服务的地址。因此，成功部署微服务应用需要开发人员有更好地部署策略和高度自动化的水平。
• 总的来说(问题和挑战) ：API Gateway、服务间调用、服务发现、服务容错、服务部署、数据调用。

微服务要解决的问题

（编辑：ASP站长网）