架构

前言 在企业信息化建设中，一个常见诉求是：员工继续使用本地 AD 域账号，同时能够无缝访问 Office 365、Teams 等云端应用，并在统一策略下完成认证与权限控制。 这个问题的本质并不是“本地目录还是云目录二选一”，而是如何在安全、体验、合规之间取得平衡。混合身份认证正是为此而生：既保留本地目录的管理基础，又借助云端身份服务提升统一登录能力与安全治理能力。 本文会围绕实际落地最常遇到的核心问题展开： AD 与 Entra ID 的职责边界与协作关系 PHS、PTA、ADFS 三种方案的取舍逻辑 面向教育/组织接入场景的扩展实践（如 OneRoster、外部目录接入） 什么是混合身份认证？ Hybrid Identity 是指通过本地目录（如Microsoft Active Directory、OpenLDAP 等）与云目录（如 Microsoft Entra ID、Google Cloud Identity 等）的集成，为用户提供统一的身份验证和授权机制。这种解决方案允许用户使用单一身份访问本地和云中的资源，无论资源的位置如何。具体场景如下： 允许你或你的组织内的用户，使用 Azure AD 登录你开发的应用。 允许其他组织的用户，使用 Azure AD 登录你开发的应用。 为什么会有混合身份认证，是否可以不使用本地目录，而完全依赖云目录？ 取决于企业的具体需求，包括现有架构、协议支持、网络条件、合规性要求等。对于大多数企业，采用混合架构（本地目录+云目录）可能是更现实的选择。 我们能做的？ 了解术语概念 业务相关 沟通需要 理解深层次架构 提供产品方向 解决技术问题 一、基础概念 身份 (Identity)： 用户/设备/服务的唯一代表（用户名、邮箱等）。 认证 (Authentication, AuthN)： 证明“你是谁”（密码、指纹、短信验证码、MFA）。 授权 (Authorization, AuthZ)： 决定“你能做什么”（RBAC角色权限、ABAC属性权限）。 身份生命周期： 创建账号 -> 启用 -> 更新（改密码） -> 禁用 -> 删除。 IAM、IDP、IDM三者共同构成了现代企业身份管理与安全体系 ...

书籍链接：https://book.douban.com/subject/34782232/ 主要针对第二章的全球区域化部署技术 1 总体架构 基本原则 问题 解决方案 总体架构 2 路由服务 2.1 路由服务架构 透传技术优势： 1、无需在每一层维护一个路由表，不用过多关注路由数据一致性问题。 2、无需每次都调用路由表RPC服务，对RPC服务的依赖过大，调用量过高。 2.2 路由表设计 1、基本模型 类似位图，通过用户id将bitmap对应的位置置为1。但是我们不仅需要存储用户是否存在的信息，还需要存储用户到机房的路由，所以用4个二进制位来存储用户到机房的映射。 前三位：机房标识 最后一位：用户状态 2、分段存储 为了解决ID分布不均匀，存储浪费的问题，采取分段模式进行存储。用户没命中的段为null，不会占用内存。 3、逻辑机房 1、路由信息巨大，机房迁移成本很高。 2、使流量均匀分布。 4、一致性保障 定期MD5进行对比 2.3 路由表更新机制 基于Zookeeper实现，引入“禁写”状态，即用户的路由表更新时，该用户无法进行业务写入，从而确保业务数据的全局一致性。架构如下： 整体流程 2.4 用户路由更新方案 1、确定用户归属机房 通过对各个机房的访问统计，将延迟最少的机房确认为最近的机房。 2.5 多层路由实现 1、统一接入层路由技术 为所有网站用户提供统一的接入点，对多区域进行对等部署，并将用户归属到不同的区域。 方案：Openresty + Lua共享内存 + Redis + ProxyServer 2、服务层路由技术 业务相关，处理不同类型的数据，如：独享数据、共享数据。 1）用户优先级原则，如买家 > 卖家 > 平台运营人员。 2）数据类型及处理方法 只读类型：不需要实时一致；处理：数据异步复制 独享类型：只有一个用户可以对数据进行变更。处理：本地读写 共享数据：多个用户需要共同变更同一条数据。处理：优先级最高的用户区域作为Master，可进行本地读写。非Master区域的用户需要区分情况决定是本地读写还是跨区域读写。 全局共享数据：所有用户的行为都可以改变的数据，对一致性要求较高。处理：使用网络质量最好的机房存放数据，所有用户对全局共享数据的变更都被路由到这个机房。 3、消息层路由 异步调用时，如使用MQ进行调用，需要将消息路由到指定的机房。 ...

长轮询在配置平台的应用 1. 配置平台简介 略 2. 长轮询简介 传统的短轮询方式存在一个严重缺陷：程序在每次请求时都会新建一个HTTP请求，然而并不是每次都能返回所需的新数据。当同时发起的请求达到一定数目时，会对服务器造成较大负担。这时我们可以采用长轮询方式解决这个问题。 长轮询的基本思想是在每次客户端发出请求后，服务器检查上次返回的数据与此次请求时的数据之间是否有更新，如果有更新则返回新数据并结束此次连接，否则服务器“hold”住此次连接，直到有新数据时再返回相应。而这种长时间的保持连接可以通过设置一个较大的HTTP timeout实现。在服务端消息推送方面，长轮询有着广泛的应用。 3. 请求模型 3.1 同步请求模型 这是我们日常最常用同步请求模型，所有动作都交给同一个 Tomcat 线程处理，所有动作处理完成，线程才会被释放回线程池。 如果业务需要较长时间处理，那么这个 Tomcat 线程其实一直在被占用，随着请求越来越多，可用 I/O 线程越来越少，直到被耗尽。这时后续请求只能等待空闲 Tomcat 线程，这将会加长了请求执行时间，或者直接被拒绝，客户端会报connect refused异常。 如果客户端不关心返回业务结果，这时我们可以自定义线程池，将请求任务提交给线程池，然后立刻返回。 3.2 异步请求模型 Servlet3 引入异步 Servelt 新特性，可以完美解决上面的需求。 异步 Servelt 执行请求流程： 将请求信息解析为 HttpServletRequest 分发到具体 Servlet 处理，将业务提交给自定义业务线程池，请求立刻返回，Tomcat 线程立刻被释放 当业务线程将任务执行结束，将会将结果转交给 Tomcat 线程 通过 HttpServletResponse 将响应结果返回给等待客户端 引入异步 Servelt3 整体流程如下： 3.3 应用场景 1、增加系统吞吐量 拿Tomcat作为Servlet容器来说，无论是计算型请求还是IO型请求，都是交给Tomcat容器线程来建立连接和负责业务逻辑处理，如果将IO型请求或者RT（响应时间）比较高的请求业务逻辑处理，通过异步请求来实现，可以尽早地释放连接线程，业务逻辑交由业务线程池处理，那么连接线程池可以接收更多的请求，从而提高了系统吞吐量。 2、服务端消息推送 消息推送，对于一些服务端发生变更，需要向客户端发送消息通知的场景，可以通过异步请求来实现。 3.4 异步请求实现 1、 AsyncContext HttpServletRequest#startAsync 获取 AsyncContext 异步上下文对象 使用自定义的业务线程池处理业务逻辑 业务线程处理结束，通过 AsyncContext#complete 返回响应结果 ExecutorService executorService = Executors.newFixedThreadPool(10); @RequestMapping("/hello") public void hello(HttpServletRequest request) { AsyncContext asyncContext = request.startAsync(); // 超时时间 asyncContext.setTimeout(10000); executorService.submit(() -> { try { // 休眠 5s，模拟业务操作 TimeUnit.SECONDS.sleep(5); // 输出响应结果 asyncContext.getResponse().getWriter().println("hello world"); log.info("异步线程处理结束"); } catch (Exception e) { e.printStackTrace(); } finally { asyncContext.complete(); } }); log.info("servlet 线程处理结束"); } 2、 DeferredResult Servlet3.0 提供了异步处理请求的特性，DeferredResult 是Spring基于 Servlet 3.0 对异步请求的支持实现，SpringMVC 3.2 之后引入新的类 DeferredResult，目的是对于请求提供异步处理方式，释放容器连接，支持更多的并发。或者基于它的超时机制来做一些长轮询相关的事情。 ...