Spring WebSocket是可以使用token进行认证连接的，一定是你哪个部分配置错误导致的。 代码配置实例 /** * WebSocket配置 * @author lnkToKing */ @Configuration /* * 开启使用STOMP协议来传输基于代理（message broker）的消息 * 启用后控制器支持作用@MessgeMapping注解 */ @EnableWebSocketMessageBroke public class WebSocketConfig extends AbstractWebSocketMessageBrokerConfigurer { @Value("${token-secret-key}") private String tokenSecretKey; //注册STOMP协议节点并映射url @Override public void registerStompEndpoints(StompEndpointRegistry registry) { //添加连接节点 registry.addEndpoint("/endpoint").addInterceptors(new HandshakeInterceptor() { /** * websocket握手 */ @Override public boolean beforeHandshake(ServerHttpRequest request, ServerHttpResponse response, WebSocketHandler wsHandler, Map<String, Object> attributes) throws Exception { ServletServerHttpRequest req = (ServletServerHttpRequest) request; //获取token认证 String token = req.getServletRequest().getParameter("token"); //解析token获取用户信息 Principal user = parseToken(token); if(user == null){ //如果token认证失败user为null，返回false拒绝握手 return false; } //保存认证用户 attributes.put("user", user); return true; } @Override public void afterHandshake(ServerHttpRequest request, ServerHttpResponse response, WebSocketHandler wsHandler, Exception exception) { } }).setHandshakeHandler(new DefaultHandshakeHandler(){ @Override protected Principal determineUser(ServerHttpRequest request, WebSocketHandler wsHandler, Map<String, Object> attributes) { //设置认证用户 return (Principal)attributes.get("user"); } }) .setAllowedOrigins("*") //允许跨域 .withSockJS(); //指定使用SockJS协议 } /** * 根据token认证授权 * @param token */ private Principal parseToken(String token){ //TODO 解析token并获取认证用户信息 return null; } }... 展开详请

微服务架构的好处 微服务架构模式有很多好处。首先，通过分解巨大单体式应用为多个服务方法解决了复杂性问题。在功能不变的情况下，应用被分解为多个可管理的分支或服务。每个服务都有一个用RPC-或者消息驱动API定义清楚的边界。微服务架构模式给采用单体式编码方式很难实现的功能提供了模块化的解决方案，由此，单个服务很容易开发、理解和维护。 第二，这种架构使得每个服务都可以有专门开发团队来开发。开发者可以自由选择开发技术，提供API服务。当然，许多公司试图避免混乱，只提供某些技术选择。然后，这种自由意味着开发者不需要被迫使用某项目开始时采用的过时技术，他们可以选择现在的技术。甚至于，因为服务都是相对简单，即使用现在技术重写以前代码也不是很困难的事情。 第三，微服务架构模式是每个微服务独立的部署。开发者不再需要协调其它服务部署对本服务的影响。这种改变可以加快部署速度。UI团队可以采用AB测试，快速的部署变化。微服务架构模式使得持续化部署成为可能。 最后，微服务架构模式使得每个服务独立扩展。你可以根据每个服务的规模来部署满足需求的规模。甚至于，你可以使用更适合于服务资源需求的硬件。比如，你可以在EC2 Compute Optimized instances上部署CPU敏感的服务，而在EC2 memory-optimized instances上部署内存数据库。 微服务架构的不足 Fred Brooks在30年前写道，“there are no silver bullets”，像任何其它科技一样，微服务架构也有不足。其中一个跟他的名字类似，『微服务』强调了服务大小，实际上，有一些开发者鼓吹建立稍微大一些的，10-100 LOC服务组。尽管小服务更乐于被采用，但是不要忘了这只是终端的选择而不是最终的目的。微服务的目的是有效的拆分应用，实现敏捷开发和部署。 另外一个主要的不足是，微服务应用是分布式系统，由此会带来固有的复杂性。开发者需要在RPC或者消息传递之间选择并完成进程间通讯机制。更甚于，他们必须写代码来处理消息传递中速度过慢或者不可用等局部失效问题。当然这并不是什么难事，但相对于单体式应用中通过语言层级的方法或者进程调用，微服务下这种技术显得更复杂一些。 另外一个关于微服务的挑战来自于分区的数据库架构。商业交易中同时给多个业务分主体更新消息很普遍。这种交易对于单体式应用来说很容易，因为只有一个数据库。在微服务架构应用中，需要更新不同服务所使用的不同的数据库。使用分布式交易并不一定是好的选择，不仅仅是因为CAP理论，还因为今天高扩展性的NoSQL数据库和消息传递中间件并不支持这一需求。最终你不得不使用一个最终一致性的方法，从而对开发者提出了更高的要求和挑战。 测试一个基于微服务架构的应用也是很复杂的任务。比如，采用流行的Spring Boot架构，对一个单体式web应用，测试它的REST API，是很容易的事情。反过来，同样的服务测试需要启动和它有关的所有服务（至少需要这些服务的stubs）。再重申一次，不能低估了采用微服务架构带来的复杂性。... 展开详请

我先说下什么是微服务吧。 微服务（Microservice Architecture，简称 MSA），这个概念其实很早就有了，但是一直没有人去具体整理和总结，所以到现在也没有一个清晰明确的概念。微服务不是框架，也不是系统，只是一种架构风格。所以我们用的 dubbo 、Spring Cloud 等框架，都是分布式服务框架。只是这种分布式服务框架都是微服务架构必不可少的基础能力，微服务一定是分布式的（参考腾讯云）。 常用的微服务架构我在此简单介绍如下几个：ZeroC Ice Grid、Dubbo、Spring Cloud。 ZeroC IceGrid基于RPC框架，并由此发展而来，具有良好的性能与分布式能力，如下所示是它的整体示意图： image.png IceGrid提供了grid.xml 来描述与定义一个基于微服务架构的Application，一个命令行工具一键部署这个Application，还提供了发布二进制程序的辅助工具——icepatch，它大大减少了分布式集群下微服务系统的运维工作量； Dubbo使用RPC通讯协议，Dubbo支持各种通信协议，而且消费方和服务方使用长链接方式交互，通信速度上略胜Spring Cloud ，但是Dubbo需要自己开发一套API 网关； Spring Cloud：Spring Cloud 使用HTTP协议的REST API，可以通过Zuul配置即可完成网关定制； 以上。... 展开详请

首先我们先简单的介绍一下什么是面向服务的架构，它的英文全称：service-oriented architecture，这不是一种特定的技术，而是一种分布式计算的软件设计方法。它是一个组件模型，它将应用程序的不同服务通过这些服务之间定义好的接口联系起来。接口是采用中立的方式进行定义的，通用性高，可以独立在不同的硬件平台、操作系统和编程语言上进行使用。这使得构建在各种各样的系统中的服务可以以一种统一和通用的方式进行交互。（引用维基百科） 以下指导原则是开发、维护和使用SOA的基本原则： 1、 可重复使用，高交互操作性。 2、 通用的匹配开放标准，对各厂商的产品兼容性高。 3、服务的识别和分类，提供和发布，监控和跟踪 SOA-Diagram-01.jpg 那么微服务架构是什么呢？微服务（Microservices）是一种软件的架构风格。它的具体架构可以参考这篇文章。它是以专注于单一责任与功能的小型功能区块 (Small Building Blocks) 为基础，利用模组化的方式组合出复杂的大型应用程序，各功能区块使用与语言无关 (Language-Independent/Language agnostic) 的 API 集相互通讯。（引用维基百科） Richardson-microservices-part1-1_monolithic-architecture.png 了解了这么多，简单介绍一下这两者之间的区别： 1. 微服务说的直白一些就是组合化，它的每部分需要实现的功能可以有不同的小程序单独构成，然后相互之间协同实现一个大的目标。这个角度上来说，它们是一脉相承的额，但是面向服务的架构，没有微服务的分离度高，相互之间的关联度还是相对较高。举一个很简单的例子，就拿常见的医院和诊所，医院就是微服务架构，不同的部分分工不同，但是诊所就是一个医生必须全科，啥都要做，这就是SOA。 2. 微服务相比较来说，在各个组件上可以使用不一样的编程语言。... 展开详请

微服务能解决了单体应用以及SOA带来的的问题，但是微服务使整个应用服务增多，服务间通讯更复杂，也会带来大量 的问题。比如单体如何拆分成多个微服务，团队间沟通更多，运维成本增高，分布式事务问题，依赖管理变得复杂，测试 更加困难，故障更难于定位等等。 微服务架构能够解决单体架构带来的问题。但是在微服务架构中，一个整体的程序被拆分为许多子微服务。每个微服务实现某一个单一的功能，但是这使得应用程序的应用服务变多，这就使得这些微服务程序之间的通信变得十分复杂。而在程序运行过程中存在着大量的业务逻辑，这往往需要各个微服务之间交换大量的数据。这就带来了许多微服务通信的问题。但是微服务之间是如何通信的呢？ 1、客户端到服务端通信，API Gateway方法。 API Gateway是解决微服务通信的一个不错的方法。以客户端为例。一个客户端可以向多个微服务中的任意一个微服务发出请求。API Gateway负责请求转发、合成和协议转换。所有请求都要先经过API Gateway，然后再将请求转发到对应的微服务中。 2、进程通信IPC 这种通信不但可以实现一对一、一对多。还可以实现同步和异步请求。 ... 展开详请

首先，使用微服务简单模式进行开发的四个步骤： 第一步：沿用组织中现有的技术体系开发单一职责的微服务。 第二步：服务提供方将地址信息注册到注册中心，调用方将服务地址从注册中心拉下来。 第三步：通过门户后端（服务网关）将微服务 API 暴露给门户和移动 APP。 第四步：将管理端模块集成到统一的操作界面上。 为了实现以上 4 点，相对应的就是下面必需掌握的基础技术（必需的组件）。 注册中心、服务发现、负载均衡：对应上边第一步与第二步 服务网关：对应上边第三步 管理端集成框架：对应上边第四步 其次，微服务架构是由一系列职责单一的细粒度服务构成的 分布式网状结构，服务之间通过轻量机制进行通信，这时候必然引入一个服务注册发现问题，也就是说服务提供方要将自己的服务地址注册到某个地方（服务注册中心， Service Registry Center），服务的调用方可以从服务注册中心找到需要调用的服务的地址（服务发现，Service Discovery）。 同时，服务提供方一般以集群方式提供服务，则引入了负载均衡 的需求。 目前主要的服务注册、发现和负载均衡方案有三种： 1、集中式 LB 方案 2、进程内 LB 方案 3、主机独立 LB 进程方案... 展开详请