微服务
Spring Cloud Gateway
· ☕ 3 min read
介绍 技术 特性 适用场景 说明 Spring Cloud Gateway - 基于 Spring Framework 5,Project Reactor 和 Spring Boot 2.0 - 动态路由 - Predicates 和 Filters 作用于特定路由 - 集成 Hystrix 断路器 - 集成 Spring Cloud DiscoveryClient - 限流 - 路径重写 - 微服务网关 - 蓝绿部署 - 官网 - Github - Doc 基本概念 Predicate Predicate 来源于 Java 8,是 Java 8 中引入的一个函数。 Predicate 接受一个输入参数,返回一个布尔值结果。该接口包含多种默认方法来将 Predicate 组合成其他复杂的逻辑(比如:与(and)、或(or)、非(negate))。

Nacos
· ☕ 3 min read
介绍 技术 特性 适用场景 说明 Nacos - 服务发现和服务健康监测 - 动态配置服务 - 动态 DNS 服务 - 服务及其元数据管理 - 与Spring Cloud、Kubernetes、Dubbo等无缝的融合与支持 - 支持单机模式、集群模式、多集群模式部署 - 动态服务发现 - 服务配置 - 服务流量治理 - 官网 - Doc - Github - 下载 OpenAPI 参考 Open API 指南 示例: 1 2 3 4 5 6 7 8 9 10 11 # 服务注册 $ curl -X POST 'http://127.0.0.1:8848/nacos/v1/ns/instance?serviceName=nacos.naming.serviceName&ip=20.18.7.10&port=8080' # 服务发现 $ curl -X GET 'http://127.

SpringCloud
· ☕ 1 min read
Spring Cloud微服务架构 微服务拆分方法 微服务拆分方法 说明 基于业务逻辑拆分 将系统中的业务模块按照职责范围识别出来,每个单独的业务模块拆分为一个独立的服务 基于可扩展拆分 按照稳定性排序,区分出稳定服务和变动服务 基于可靠性拆分 将可靠性高的核心服务和可靠性要求低的非核心服务拆分开来,重点保证核心服务的高可用 基于性能拆分 将对性能压力大的模块拆出来,避免影响其它服务,而且对其做性能提升、高可用等优化都简单高效 Spring Cloud与Spring Boot版本匹配关系 Spring Cloud版本 Spring Boot版本 Greenwich 2.1.x Finchley 2.0.x Edgware 1.5.x Dalston 1.5.x Camden 1.4.x、1.5.x Brixton EOL Angel EOL 参考 文档 Spring Cloud Sleuth 网站 Spring Cloud中文网 GitBook 使用Spring Cloud与Docker实战微服务 博客 Spring Cloud 系列文章 方志朋的专栏 风戏辞

微服务架构
· ☕ 1 min read
什么是微服务 一种可以采用不同开发语言开发,将单体应用开发为一组小型服务,每个服务运行在自己的进程中,服务间通信采用轻量级通信机制,可以通过全自动部署机制独立部署。 微服务架构图 微服务架构的特征 每个微服务可独立运行在自己的进程里 一系列独立运行的微服务共同构建起整个系统 服务独立,一个微服务只关注某个特定的功能 轻量级通信机制 可以使用不同的开发语言开发 全自动部署机制 微服务架构的优点 易于开发和维护 单个服务只会关注一个特定的业务功能,所以它业务清晰、代码量较少。 单个微服务启动较快 易于局部修改和部署 技术栈不受限 可以结合项目业务及团队的特点,合理地选择技术栈。 细粒度的伸缩和扩展 微服务架构面临的挑战 运维要求较高 更多的服务意味着更多的运维投入。 在微服务中,需要保证几十甚至几百个服务的正常运行与协作,这个运维带来了很大的挑战。 分布式固有的复杂性 微服务构建的是分布式系统。 对于分布式系统,系统容错、网络延迟、分布式事务等都会带来巨大的挑战。 接口调整成本高 如果修改某一个服务的API,使用了所有该接口的服务都需要做调整。 重复劳动 很多服务可能都会用到相同的功能,而这个功能并没有达到分解为一个服务的程度,这个时候,可能多个服务都会开发这一个功能,从而导致代码重复。 在多语言环境下更是如此。 微服务技术选型考虑因素 文档丰富程度 社区活跃度 技术栈生态 开发效率 运行效率 成功案例 单体应用架构的优点 易于开发 易于部署 易于测试 单体应用架构面临的挑战 复杂性高 模块多、模块边界模糊、依赖关系不清晰、代码质量参差不齐 …… 技术债务 随着时间推移、需求变更和人员更迭,会逐渐形成应用程序的技术债务,并且越积越多。 “不坏不休”这在软件开发中非常常见,在单体应用中这种思想更甚。 运维风险 系统升级、Bug修复、故障排查都存在很大的风险。 部署频率低 全量部署方式时间长、影响范围大、风险高,这使得单体应用项目上线部署的频率较低。 系统性风险 某个bug可能导致整个应用崩溃。 扩展能力受限 单体应用只能作为一个整体进行扩展,无法根据业务模块的需要进行伸缩。 阻碍技术创新 单体应用往往使用统一的技术平台或方案解决所有的问题,团队中的每个成员都必须使用相同的开发语言和框架,要想引入新框架或新技术平台会非常困难。