ASPIRE

服务化与微服务

=Start=

缘由：

整理一些在微信公众号、博客里看到的和「服务化」与「微服务」相关的文章、资料，方便学习和参考。

正文：

参考解答：
为什么要进行服务化？

随着数据量、并发量、业务复杂度的增长，互联网架构会出现以下问题：

  1. 代码到处拷贝
  2. 底层复杂性扩散
  3. 基础库（so/jar/dll）耦合
  4. SQL质量得不到保障，业务相互影响
  5. 数据库耦合

“服务化”是一个很好的解决上述痛点的方案。但是服务化之后，随着规模的扩大，一定要考虑“服务治理”，否则服务之间的依赖关系会乱成麻。

不同粒度的服务化各有什么优劣？

总的来说，细粒度拆分的优点有：

  1. 服务都能够独立部署
  2. 扩容和缩容方便，有利于提高资源利用率
  3. 拆得越细，耦合相对会减小
  4. 拆得越细，容错相对会更好，一个服务出问题不影响其他服务
  5. 扩展性更好
  6. …

细粒度拆分的不足也很明显：

  1. 拆得越细，系统越复杂
  2. 系统之间的依赖关系也更复杂
  3. 运维复杂度提升
  4. 监控更加复杂
  5. 出问题时定位问题更难
  6. …

关于微服务架构的“粒度”问题，需要根据各自业务、场景的实际情况进行选取，并没有一种万能的方案可以cover住所有场景。

参考链接：

=END=

Docker

,
,

《 “服务化与微服务” 》 有 32 条评论

  2. 从 Spring Cloud 看一个微服务框架的「五脏六腑」
    http://www.importnew.com/28514.html
    `
    Spring Cloud 是一个基于 Spring Boot 实现的微服务框架，它包含了实现微服务架构所需的各种组件。

    面向服务的架构（SOA）和微服务架构是目前两种主流的服务化架构。准确地说微服务是去 ESB（企业服务总线）的 SOA。ESB 借鉴了计算机组成原理中的通信模型 —— 总线，所有需要和外部系统通信的系统，通过 ESB 进行标准化地转换从而消除协议、异构系统之间的差异，这样就可以利用现有的系统构建一个全新的松耦合的异构的分布式系统。微服务架构去掉 ESB，本质上是一种去中心化的思想。

    服务在哪？（服务治理问题）
    怎么调用？（服务调用问题）

    服务治理为心脏，路由网关、消息中心、断路器、链路追踪、配置中心等为依托，构造了整个微服务框架的「五脏六腑」。当然，一个微服务系统远比本文所写的复杂得多，尤其是在不同的业务场景之下，因此想要更深入地了解它就需要我们不断地去实践。而作为前端，我了解这些内容一是为了更好地了解整个请求的流程，二是为了后续在 SOA 中接入 Node 子服务积累相关知识。

    最后分享一句有趣的调侃 Spring 的话：在 Spring 中没有什么是一个注解解决不了的，如果有，那么就用两个注解。
    `

    回复

  8. 微服务化的基石——持续集成
    https://mp.weixin.qq.com/s/PDrzITSgkDgvnm01APOixQ
    `
    一、持续集成对于微服务的意义：拆之前要先解决合的问题
    从一个简单的单体应用，变成如此复杂的微服务架构，除了关心怎么拆的问题，还必须关注：
    　　如何控制拆的风险
    　　如何保证代码质量
    　　如何保证功能不变，不引入新的Bug

    答案当然就是集成，从一开始就集成，并且不断的集成，反复的将拆分的模块重新组合，看看是否能够顺利组合起来，并且保证功能的不变。

    要是不没事儿就组合一下，天知道几个月以后还能不能合的起来。

    二、持续集成就是不断的尝试在一起
    为什么需要一个统一的代码仓库Git来做代码管理呢？是为了代码集成在一起。
    为什么需要进行构建build呢？就是代码逻辑需要集成在一起，编译不出错
    为什么要单元测试呢？一个模块的功能集成在一起能够正确工作。
    为什么需要联调测试Staging环境呢？需要将不同模块之间集成在一起，在一个类生产的环境中进行测试。
    最终才是部署到生产环境中，将所有人分开做的工作才算真正的合在了一起。

    三、持续集成，持续交付，持续部署，敏捷开发，DevOps都啥关系？
    持续集成往往指对代码的提交，构建，测试的过程，也就是上述的在一起的过程。
    持续交付是指将集成好的交付物，例如war，jar，或者容器镜像，部署在联调环境，或者预发环境的过程。
    持续部署是指将交付物持续部署在生产环境的过程。

    四、从一个持续集成的日常，看上述的几个概念如何实践

    五、有关代码结构

    六、有关接口设计规范

    七、有关代码设计

    八、有关配置文件

    九、有关数据库版本
    `

    回复

  11. 微服务架构实践（日志收集）
    https://mp.weixin.qq.com/s/9AdvXP7gEuCvuR70DYW43w
    `
    任何复杂的应用程序偶尔都会出现错误。在微服务应用程序中，需要跟踪几十甚至几百个服务发生的情况。要获取系统的整体视图，日志记录和监控至关重要。在微服务架构中，一个业务请求会经历多个服务，收集端到端链路上的日志能够帮助我们判断错误发生的具体位置。
    `

    回复

  12. 微服务的10个挑战和解决方案
    http://mushiming.top/mushblog/archives/823
    https://dzone.com/articles/10-challenges-of-microservices-and-solutions-tips
    `
    1.数据同步 – 我们使用事件源代码架构来使用异步消息传递平台解决此问题。传奇设计模式可以应对这一挑战。

    2.安全性 – API网关可以解决这些挑战。Kong非常受欢迎，并且是开源的，并且正在被许多公司用于生产。还可以使用JWT令牌，Spring Security和Netflix Zuul / Zuul2为API安全性开发自定义解决方案。还有企业解决方案，如Apigee和Okta（两步认证）。Openshift用于公共云安全的顶级功能，如基于Red Hat Linux Kernel的安全性和基于命名空间的app-to-app安全性。

    3.版本控制 – 这将由API注册表和发现API使用动态Swagger API处理，动态Swagger API可以动态更新并与服务器上的使用者共享。

    4. 发现 – 这将由Kubernetes和OpenShift等API发现工具解决。它也可以在代码级使用Netflix Eureka完成。但是，使用业务流程层执行此操作会更好，并且可以通过这些工具进行管理，而不是通过代码和配置进行维护。

    5.数据过期 – 应始终更新数据库以提供最新数据。API将从最近更新的数据库中获取数据。还可以为数据库中的每个记录添加时间戳条目，以检查和验证最近的数据。可以根据业务需求使用可定义的驱逐策略来使用和自定义缓存。

    6.调试和记录 – 有多种解决方案。可以通过将日志消息推送到异步消息传递平台（如Kafka，Google PubSub等）来使用外化日志记录。客户端可以在标头中为REST API提供关联ID，以跟踪所有pod / Docker容器中的相关日志。此外，可以使用IDE或检查日志在每个微服务上单独完成本地调试。

    7.测试 – 可以通过模拟REST API或集成/依赖API来解决此问题，这些API不可用于使用WireMock，BDD，Cucumber，集成测试，使用JMeter进行性能测试以及任何良好的分析工具（如Jprofiler）进行测试， DynaTrace，YourToolKit，VisualVM等

    8.监控 – 监控可以使用开源工具，如Prometheus与Grafana结合使用，创建仪表和矩阵，Kubernetes / OpensShift，Influx DB，Apigee，结合Grafana和Graphite。

    9. DevOps支持 – 使用最先进的DevOps工具（如GCP，Kubernetes和OpenShift与Jenkins）可以解决微服务部署和支持相关的挑战。

    10.容错 – 如果给定SLA / ETA的API没有响应，Netflix Hystrix可用于断开电路。
    `

    回复

  13. 程序员练级攻略（2018）：微服务
    https://time.geekbang.org/column/article/11116
    `
    微服务是分布式系统中最近比较流行的架构模型，也是 SOA 架构的一个进化。微服务架构并不是银弹，所以，也不要寄希望于微服务构架能够解决所有的问题。微服务架构主要解决的是如何快速地开发和部署我们的服务，这对于一个能够适应快速开发和成长的公司是非常必要的。同时我也觉得，微服务中有很多很不错的想法和理念，所以学习微服务是每一个技术人员迈向卓越的架构师的必经之路。
    `
    首先，你需要看一下，Martin Fowler 的这篇关于微服务架构的文档：
    Microservice Architecture
    http://martinfowler.com/articles/microservices.html
    https://blog.csdn.net/wurenhai/article/details/37659335 #中译版
    这篇文章说明了微服务的架构与传统架构的不同之处在于，微服务的每个服务与其数据库都是独立的，可以无依赖地进行部署。你也可以看看 Martin Fowler 老人家现身说法的视频。

    另外，你还可以简单地浏览一下，各家对微服务的理解。
    AWS 的理解 – What are Microservices?
    https://aws.amazon.com/microservices/

    Microsoft 的理解 – Microservices architecture style
    https://docs.microsoft.com/en-us/azure/architecture/guide/architecture-styles/microservices

    Pivotal 的理解 – Microservices
    https://pivotal.io/microservices

    回复

  15. 讨论微服务之前，你知道微服务的 4 个定义吗？
    https://wizardbyron.github.io/2018/09/14/2018-09-14-four-definitions-of-microservices/
    `
    关于“什么是微服务”的问题，其实并没有一个统一的认识。这些年在不同的场合里和不同背景的朋友都在探讨微服务。但聊得越多，就越发现大家聊的不是同一回事。和 DevOps 一样，“微服务”也是一个内涵十分广泛的词。本文从“Microservice“这个概念的源头出发，总结了 4 个常用的微服务定义。

    本文总结了微服务常见的 4 个定义。但比这些定义更重要的是你为什么要用微服务？你想从微服务中获得什么益处？你是否了解为了追求这些益处所带来的代价？如果不先明确这些问题，在不理解微服务架构或者技术所带来的的风险和成本。盲目的采用所谓的微服务，可能带来的结果并不理想。
    `

    回复

  17. 聊聊分布式链路追踪
    http://lidawn.github.io/2018/12/26/distribute-tracing/
    `
    1. 起因
    2. 什么是链路追踪
    3. Dapper
    3.1. Trace、Span、Annotations
    3.2. 带内数据与带外数据
    3.3. 采样
    3.4. 存储
    4. Zipkin
    4.1. 架构
    4.2. 数据模型
    4.2.1. Span
    4.2.2. 带内数据与采样机制
    4.3. 数据埋点及上报过程
    5. Open-Tracing
    6. 参考
    `

    回复

  18. 天机阁——全链路跟踪系统设计与实现
    https://mp.weixin.qq.com/s/RBPJFrj2mcTUjbm4aH9TRg
    `
    为了支撑日益增长的庞大业务量，业界大量使用微服务架构。服务按照不同的维度进行拆分，互联网应用构建在不同的软件模块集上，这些软件模块可能是由不同的团队开发、可能使用不同的编程语言来实现、可能布在了几千台服务器，横跨多个不同的数据中心，分布式系统变得日趋复杂。

    如何快速进行故障定位？如何准确进行容量评估？如何动态展示服务的链路？如何进行系统性能优化？这是分布式系统给后台开发同学带来的四大挑战。业界都是通过链路跟踪系统来解决以上问题，然而腾讯在链路跟踪方面比较欠缺。为了填补此空白，“天机阁”系统横空出世。

    “天机阁”通过采集、存储、分析分布式系统中的trace数据、指标数据和日志数据，完成全链路跟踪，从而解决上述问题。目前天机阁接入了1200+个服务，trace数据上报峰值500万/分钟，指标数据上报峰值1.3亿/分钟，日志数据每天30T。如此海量的数据天机阁是怎样处理的？天机阁的链路跟踪是怎样实现的？又是怎样做到低侵入，低开销的？这些问题本文将一一为您揭秘。
    `

    回复

  19. 小团队的微服务之路
    https://deanwangpro.com/2019/02/18/road-of-microservice/
    `
    1. 单体应用时代
    1.1. 接口定义
    1.2. 持续集成(CI)
    2. 微服务时代
    2.1. 服务拆分原则
    2.2. 框架选择
    2.3. 架构改造
    2.4. 自动化部署
    2.5. 链路跟踪
    2.6. 运维监控
    3. 容器化时代
    3.1. 架构改造
    3.2. Spring Cloud与k8s的融合
    3.3. CI的改造
    4. 小结
    `

    回复

  20. 微服务化后缓存怎么做
    https://paper.tuisec.win/detail/c0932e3ebc09c6c
    https://toutiao.io/posts/7q0a3u/preview
    https://martin.kleppmann.com/2012/10/01/rethinking-caching-in-web-apps.html
    `
    缓存更新本身就是一个难解的问题，在微服务化后，多个服务就更加复杂了。涉及到跨服务的多级缓存一致性的问题。

    所以对大部分的业务，我们可以遵循这样的原则来简单有效处理。

    · 对数据的有效性比较敏感的调用都收敛到服务内部（领域内部应该更合适），不要暴露给调用方， 领域内部做数据的缓存失效控制

    · 缓存预计算（有些页面的地方不希望首次打开慢）的逻辑也应该放在领域内控制，不要暴露给调用方。 在领域内部控制在不同的地方使用不同的缓存策略，比如更新数据的地方需要获取及时的数据。比如商品的价格，和商品的所属类目更新频次不同，需要有不同的过期时间。

    · 跨服务调用为了减少rpc调用，可以再进行一层缓存。因为这些调用可以接受过期的数据，再进行一层缓存没问题，expired time叠加也没多大影响（expire time在这边主要是影响缓存的命中数）

    扩展：如果后续有case在跨服务的调用时，对数据的过期比较敏感，并且在调用方也做了缓存，那就是跨服务的多级缓存一致性的问题。那就需要服务方告知调用方缓存何时失效，使用消息队列or其他方式来实现。
    `

    回复

  24. 从技术角度讨论微服务
    https://mp.weixin.qq.com/s/UukNe5i5WxzRN2rLYeL52Q
    `
    本文希望从技术角度来探讨下微服务，因此，不会过多地谈及如何根据业务进行微服务划分，更多是介绍微服务的相关技术，微服务的业务划分方法可参考“领域驱动设计“相关方法论。

    微服务的两个程度
    一、服务化
    二、容器化

    服务注册发现
    一、最简单的服务注册发现
    二、基于中间件的服务注册发现
    三、基于容器治理平台的服务注册发现

    简单总结
    　　我认为，从架构的层面来看微服务架构，应该是这样的：
    　　扩展性：降低复杂系统的耦合度、沟通成本以及系统复杂度，需求快速响应；
    　　伸缩性：可以通过增加资源的方式来快速应对海量并发（仅仅是并发层面，大数据量还是需要根据业务进行分片或分割）；
    　　稳定性：微服务治理平台，PaaS平台保证了系统的高可用性，可以降低业务的中断时间；
    　　安全性：和传统架构的要求差别不大，但是由于网关和网格（Service Mesh）的存在，使得安全处理，APM等的实现更加简单。

    　　另外，我认为微服务可以通过部署的方式来实现功能或模块的复用，一定程度上代替了过往通过jdk/sdk来实现共用的方式；使得开发更加灵活，也使得开发可以更加关注于业务，而非各种边边角角的公共（轮子）功能。
    `

    回复

  25. 战术模式–领域事件
    http://www.geekhalo.com/2019/04/16/ddd/tactics/event/
    `
    1 理解领域事件
    2 实现领域事件
    2.1 创建领域事件
    2.1.1 事件命名
    2.1.2 事件属性
    2.1.3 事件方法
    2.1.4 事件唯一标识
    2.2 发布领域事件
    2.2.1 发布订阅模型
    2.2.2 基于 ThreadLocal 的事件发布
    2.2.3 基于实体缓存的事件发布
    2.2.4 由调用方发布事件
    2.3 订阅领域事件
    2.4 处理领域事件
    2.4.1 保证聚合间的数据一致性
    2.4.2 替换批量处理
    2.4.3 实现事件源模式
    2.4.4 进行限界上下文集成
    2.5 异步处理领域事件
    2.6 内部事件与外部事件
    2.6.1 内部事件
    2.6.2 外部事件
    3 实现领域事件模式
    3.1 封装领域事件的“发布-订阅”模式
    3.2 内存总线处理内部事件，消息队列处理外部事件
    3.3 使用实体缓存领域事件
    3.4 使用 IOC 容器的事件发布功能

    4 小结
    领域事件是发生在问题域中的事实，它是通用语言的一部分。
    领域事件优先使用发布-订阅模式，会发布事件并且触发相应的事件处理器。
    限界上下文内，优先使用内部事件和内存总线；限界上下文间，优先使用外部事件和消息队列。
    领域事件使异步操作变得简单。
    领域事件为聚合间提供了最终一致性。
    领域事件可以将大的批量操作简化为许多小的业务操作。
    领域事件可以完成强大的事件存储。
    领域事件可以完成限界上下文间的集成。
    领域事件是更复杂架构（CQRS）的一种支持。
    `

    回复

  26. 技术分享之service mesh (k8s&istio)的那些事儿
    http://xiaorui.cc/2019/08/24/%E6%8A%80%E6%9C%AF%E5%88%86%E4%BA%AB%E4%B9%8Bservice-mesh-k8sistio%E7%9A%84%E9%82%A3%E4%BA%9B%E4%BA%8B%E5%84%BF/
    `
    这次分享的话题主要围绕微服务service mesh架构的实践，话题也是拆分了三个子topic，分别是微服务的演进史、kubernets、istio。本想做个简单偏科普的介绍，后来发现如单纯只是讲k8s、istio的介绍使用，而不去稍微讲点原理设计，可能会导致ppt的质量显得不高级，所以就又增加了不少原理性的介绍。
    `
    https://github.com/rfyiamcool/share_ppt
    http://xiaorui.cc/static/service_mesh.pdf

    回复

  27. [译] 微服务的设计模式
    https://www.cnblogs.com/dongxishaonian/p/12039027.html
    https://dzone.com/articles/design-patterns-for-microservices
    `
    微服务架构已经成为现代应用程序开发中公认的技术选择。尽管它解决了某些问题，但不是灵丹妙药。它有几个缺点，使用这种体系架构时，还需要解决许多问题。这就需要学习这些问题的通用模式，并通过可重用的解决方案来解决它们。因此，有必要讨论微服务的设计模式。在深入研究设计模式之前，我们需要了解微服务架构的构建原理：
    1.可扩展性
    2.可用性
    3.弹性
    4.独立自治性
    5.去中心化治理
    6.失败隔离
    7.自动配置
    8.通过DevOps持续交付

    应用所有这些原则会带来一些挑战和问题。让我们讨论这些问题及其解决方案。

    1. 分解模式
    1.1. 按业务能力分解
    1.1.1. 问题
    1.1.2. 解决
    1.2. 按子域分解
    1.2.1. 问题
    1.2.2. 解决
    1.3. 扼杀模式
    1.3.1. 问题
    1.3.2. 解决

    2. 整合模式
    2.1. api网关
    2.1.1. 问题
    2.1.2. 解决
    2.2. 聚合器
    2.2.1. 问题
    2.2.2. 解决
    2.3. 客户端UI组合
    2.3.1. 问题
    2.3.2. 解决

    3. 数据库模式
    3.1. 每个服务一个数据库
    3.1.1. 问题
    3.1.2. 解决
    3.2. 每个服务共享数据库
    3.2.1. 问题
    3.2.2. 解决
    3.3. 命令查询职责隔离（CQRS）
    3.3.1. 问题
    3.3.2. 解决
    3.4. saga模式
    3.4.1. 问题
    3.4.2. 解决

    4. 可观察性模式
    4.1. 日志汇总
    4.1.1. 问题
    4.1.2. 解决
    4.2. 性能指标
    4.2.1. 问题
    4.2.2. 解决
    4.3. 分布式跟踪
    4.3.1. 问题
    4.3.2. 解决
    4.4. 健康检查
    4.4.1. 问题
    4.4.2. 解决

    5. Cross-Cutting Concern（横切关注）模式
    5.1. 外部配置
    5.1.1. 问题
    5.1.2. 解决
    5.2. 服务发现
    5.2.1. 问题
    5.2.2. 解决
    5.3. 断路器
    5.3.1. 问题
    5.3.2. 解决
    5.4. 蓝绿部署
    5.4.1. 问题
    5.4.2. 解决
    `

    回复

  29. Staging (cloud computing), a process used to assemble, test, and review a new solution before it is moved into production and the existing solution is decommissioned
    https://en.wikipedia.org/wiki/Staging

    互联网公司的项目会分为哪些环境？
    https://zhuanlan.zhihu.com/p/66343803
    `
    一般一个项目或者说一般公司的项目都是分几个环境的：
    1.dev或本地环境
    2.test测试环境
    3.staging预发布环境
    4.prod线上环境
    `
    项目开发中的dev, test, prod , staging 环境是什么意思
    https://blog.csdn.net/yupyuping/article/details/112131236

    软件/网络应用开发的常见环境：开发环境、测试环境、staging environment、生产环境等
    https://zhuanlan.zhihu.com/p/548921018
    `
    在较大的项目中，一般会有 staging environment。增加一个 staging environment 会增加硬件采购的成本（硬件最好和生产环境的硬件一样），并且还要进行配置并写入需要的数据。

    （一）什么是 Staging Environment？
    在最后 Bugs 都修复之后，在产品上线之前，我们会在 Staging Environment 中复制一份生产环境的内容来测试产品。它可以帮助我们检测硬件的配置、服务 servers、数据库、caches 是否正确。

    它会复制生产环境的所有依赖和配置。因此，测试人也可以在不影响用户使用的情况下，检查整个产品在真实场景下是否会出现问题。

    Staging Environment 的作用是检查整个产品以及每一个组件是否在真实环境下能够正常工作，是对于真实情况的精确模拟。

    简单地说，它是一个开发人员对于产品进行各种实验的舞台 stage，在这里我们可以进行各种试验，来确保给用户最佳的体验。

    （二）在 Staging Environment 做什么测试？
    在 Staging Environment 一般做 smoke test 和 User Acceptance Test (UAT)。

    Smoke Test 也被成为 Build Verification Test 或者是 Acceptance Test。它主要是检测重要的服务功能，即会在一个 new build 主要处在开发和整合阶段检测重要功能。

    UAT 也被成为应用测试 Application Testing 或者是末端用户测试 end-user testing。它主要是从用户角度测试产品表现，确保产品质量和用户友好性。通常来说，商业用户和产品经理是 UTA 阶段的测试者。除了测试基础的功能，我们也会测试产品的视觉表现是否匹配我们的品牌、设定、风格标准。

    除此以外，开发者也在这个环境进行 chaos engineering。chaos engineering 是持续破坏代码，来加强我们对于系统的信心的过程。尽管 chaos engineering 通常在生产环境中进行，我们也可以在 staging environment 中进行。它帮助我们尽早发现产品可能在生产环境中出现的潜在 Issue。
    `
    移除 Staging 环境，加快部署过程
    https://www.infoq.cn/article/acdwibevistcsbtxc0l1

    回复

  30. 如何快速接入统一的认证鉴权体系
    https://www.chenshaowen.com/blog/how-to-access-a-unified-auth-system-quickly.html
    `
    1. 异构系统带来的认证鉴权问题

    企业系统，可以分为以下几种类型：
    * 购买的商业软件，比如 JumpServer
    * 开源的软件，比如 Kibana、Grafana
    * 自主研发的软件，比如应用管理平台

    这里需要说明的是，认证和鉴权是两个功能:
    * 认证，证明你是你
    * 鉴权，你是管理员，而不是普通用户

    针对上面的系统，在接入认证鉴权时，主要面临如下问题:
    * 自主定制成本高，而社区支持响应慢。定制开源组件需要投入大量人力，直接对其进行定制是不合时宜的，而将需求提交到社区等待解决方案，周期太长，难解燃眉之急
    * 自研系统一个一个对接认证鉴权成本很高。每一个自研系统都需要实现一套类似的逻辑，校验登录态，验证权限规则
    * 老的系统接入困难。有些老的服务相关人员离职，几乎没人维护但又有人在使用，改不动

    对于商业购买的软件，在采购时就可对接入成本、安全性等进行评估，常常能够满足认证鉴权的需求。
    而在大型企业中，不同的部门总是习惯性建设一套自己熟悉的认证鉴权系统，导致部门与部门之间的系统割裂，形成一个一个的烟囱壁垒，信息无法在内部自由流动。这给员工带来极大不便、大大降低工作效率，削弱企业在市场上的竞争力。
    统一的认证鉴权体系是有必要的。公共的功能，通过服务化的形式提供给大家使用，不仅可以避免重复开发，还可以享受更优质的职能化服务。

    2. 服务的域名策略
    在进行登录态验证时，通常会需要获取 HTTP 请求的 Cookie。而 Cookie 的作用范围是和域名直接相关的。因此在聊统一认证鉴权之前，先了解一下服务的域名策略。

    2.1 多域名多服务
    2.2 单一域名多 Location
    由于采用单域名，这些系统之间的 Cookie 是共享的。因此只需要在该域名下写下登陆态 Cookie，用户使用其他系统时，也将处于登录状态。其他系统无需完成登录逻辑，只需要后台校验登陆态，再进行鉴权即可。

    3. 通过七层 forward-auth 接入认证鉴权

    4. 通过 sidecar 接入认证鉴权
    上面这种方式，我们是将认证放在了接入层，对业务系统没有任何改造。但是这种方式存在一个风险，如果绕过网关，就可以绕过认证。

    在网关上实现的 forward-auth 认证的是南北向流量，即用户直接访问业务系统的流量。但这却无法控制东西向流量，其他服务依然可以对受控服务进行访问。另一种方式是，采用 Sidecar 进行认证鉴权。
    我们需要开发一个 Sidecar，下沉网关层的 forward-auth，代理全部访问流量，进行统一认证鉴权之后再转发至受控业务。

    这样就需要在每个受控系统上，部署一个 Sidecar。此时，用户请求的流量应该转发给 Sidecar 而不是业务本身。

    5. 总结
    本文主要思考的是在异构的系统下，如何快速接入统一的认证鉴权体系。

    认证是证明你是你，而鉴权是证明你有权限这样做。在已有一套统一的认证鉴权系统的前提下，这里提供了两种快速接入的思路:

    第一种是，采用网关层的 forward-auth，对业务无任何入侵，在接入层完成认证鉴权。通过后端 Middleware 二次验证，能够提供进一步的安全验证。

    第二种是，采用 Sidecar 拦截受控业务的流量，进行认证鉴权之后，再转发流量。这种方式具有一定的开发量，但 Sidecar 可以复用，对业务代码没有入侵。其实，很多 Middleware 实现的功能都可以使用 Sidecar 实现，将开发成本转移到运维部署层面，当基础设施是 Kubernetes 时，我们又可以借助于 kube-apiserver 的准入控制 Webhook 实现自动注入，达到一次开发永久零成本使用的效果。
    `

    回复

发表回复

您的邮箱地址不会被公开。 必填项已用 * 标注