Spring Cloud

作者：薛҉定҉谔҉的҉猫҉ www.yuque.com/zhanghaofei/blog/xrpz9p 近几年随着react、angular、vue等前端框架兴起，前后端分离的架构迅速流行。但同时权限控制也带来了问题。 网上很多前、后端分离权限仅仅都仅仅在描述前端权限控制、且是较简单、固定的角色场景，满足不了我们用户、角色都是动态的场景。 且仅仅前端进行权限控制并不是真正意义的权限控制，它只是减少页面结构暴露、增强用户体验的功效。 场景 系统为后台管理系统，包含了用户创建、用户登录、用户管理自己的资源。用户经常会新增、删除，也可以根据工作情况随时调整页面、功能权限，所以采用用户-角色-页面权限方案实现。 为什么不行： 根据前端路由表显示左侧菜单，但vue-router的路由表主要为了组织代码，经常我们所需要的菜单并非一致。比如某个前端路由a子路由有b、c，但菜单中我们想要直接一级菜单就显示b、c或者将b、c各放到其他菜单下。所以这种非常不灵活。 一个路由是菜单还是页面？是否需要显示到菜单中？是否验证权限？哪个角色或者用户拥有权限？这些都需要写到前端路由里面，一旦有任何权限变动就要大量调整代码。 如果权限写死在前端，那么角色或者用户必须已知且固定不变。比如页面1的meta增加属性标识可访问的角色为a和b 页面 一个页面即一个前端页面，比如首页、用户管理页、资源管理页等。 基本思路为

上一版的 泰山版 发布三个多月后，阿里巴巴《Java开发手册（嵩山版）》又发布了，这个版本都新增了什么内容呢，栈长来帮你解读下： 1）新增前后端规约 14 条 之前面试我经常问求职者，既然写了前后端分离开发，那对于前后端都有些什么规范呢，大多数人说不上来，现在阿里这个规范终于来了。 这一条迟早是要来的，因为现在大多都是前后端分离开发模式，规范不能只是纯 Java 开发规范，还得约束前后端共同遵守的规则。 2）新增禁止任何歧视性用语的约定。 这一条不解释了，大家都懂，前不久 MySQL 也放弃了此类用语：《 MySQL 宣布停止使用 master、slave！ 》，没想到阿里开发手册也这么快跟上形势，优秀啊。 据说 “黑人牙膏“ 都要改名了。。细思极恐。。 3）新增涉及敏感操作的情况下日志需要保存六个月的约定。 既然是国家法律规范的，那必须规范起来，这样也有助于排查历史问题。 4）修正 BigDecimal 类中关于 compareTo 和 equals 的等值比较。 没错，BigDecimal 的等值比较应该要使用 compareTo() 方法，而不是 equals()方法。因为 equals() 会比较值和精度，而 compareTo() 会忽略精度。 5）修正 HashMap 关于 1024 个元素扩容的次数。 当 HashMap 需要存储 1024 个元素时

概念 XSS全称为 Cross Site Script ，即跨站点脚本攻击，XSS攻击是最为普遍且中招率最多的web攻击方式，一般攻击者通过在网页恶意植入攻击脚本来篡改网页，在用户浏览网页时就能执行恶意的操作，像html、css、img都有可能被攻击。 像前不久微信貌似就中招，好像是在朋友圈发送一个带有脚本的链接，然后通过点击该链接就会弹出一个提示，虽然没有造成什么影响，但这是XSS攻击最鲜明的特点。 分类 XSS现在主要分为以下两种攻击类型： 1、反射型漏洞 这种类型攻击者一般通过在网页中嵌入含有恶意攻击脚本的链接，或者通过发送带脚本的链接给受害者，这个脚本链接是攻击者自己的服务器，用户通过点击该链接就能达到攻击的目的。如 http://www.test.com/p= <script src=... />，这样受害者的网页就嵌入了这段脚本，受害者通过点击链接触发攻击脚本。 新浪微博曾经就出现过一次较为严重的XSS攻击事件，攻击者通过发送一个带有链接的微博诱导用户点击，通过点击脚本链接大量用户自动发送某些不良信息和私信并自动关注攻击者的微博账号，这是典型的反射型漏洞。 这次新浪微博事件显然是一次推广营销而已，并没有严重影响新浪的服务，然而现实中攻击者可以通过窃取用户cookie获取用户名密码等重要信息来伪造用户交易、窃取用户的财产等影响用户财产安全的恶意行为。 2、存储型漏洞

Service Mesh Virtual Meetup 是 ServiceMesher 社区和 CNCF 联合主办的线上系列直播。本期为 Service Mesh Virtual Meetup#1 ，邀请了四位来自不同公司的嘉宾，从不同角度展开了 Service Mesh 的应用实践分享，分享涵盖来自陌陌和百度的 Service Mesh 生产实践，Service Mesh 的可观察性和生产实践以及与传统微服务中可观察性的区别，还有如何使用 SkyWalking 来观测 Service Mesh。 本文根据5月13日晚，百度高级工程师罗广明的主题分享《Service Mesh 高可用在企业级生产中的实践》整理。文末包含本次分享的视频回顾链接以及 PPT 下载地址。 前言 Service Mesh 在企业落地中有诸多挑战，当与传统微服务应用共同部署治理时可用性挑战更为严峻。本次分享将以 Service Mesh 与 Spring Cloud 应用互联互通共同治理为前提，着重介绍基于 Consul 的注册中心高可用方案，通过各种限流、熔断策略保证后端服务的高可用，以及通过智能路由策略（负载均衡、实例容错等）实现服务间调用的高可用。 Service Mesh 与 Spring Cloud 应用的互通、互联 微服务是时下技术热点，大量互联网公司都在做微服务架构的推广和落地。同时

系统在生产环境出现问题时，排查问题最好的方式就是查看日志了，日志的记录尽量详细，这样你才能快速定位问题。 如果需要在Zuul中进行详细的日志记录，这两种日志必不可少。 o API请求信息 o API响应信息 前面有介绍过如何获取请求信息，文章请查看《Spring Cloud Zuul过滤器获取请求参数问题》。 今天正好又有一位朋友问我如何获取响应的数据，抽时间给大家写篇文章简单分享下。 熟悉Zuul的朋友都知道，Zuul中有4种类型过滤器，每种都有特定的使用场景，要想记录响应数据，那么必须是在请求路由到了具体的服务之后，返回了才有数据，这种需求就适合用post过滤器来实现了。 这边给大家介绍两种方式获取响应数据： 第一种 try { Object zuulResponse = RequestContext.getCurrentContext().get("zuulResponse"); if (zuulResponse != null) { RibbonHttpResponse resp = (RibbonHttpResponse) zuulResponse; String body = IOUtils.toString(resp.getBody()); System.err.println(body); resp.close(); RequestContext

1.名字的由来 前四个字母分别为 Naming 和 Configuration 的前两个字母，最后的 s 为 service 2.是什么 Nacos是一个更易于构建云原生应用的动态服务发现、配置管理和服务管理平台。 Nacos：Dynamic Naming and Configuration Service Nacos就是【注册中心+配置中心】的组合 ===》Nacos = Eureka + Config + Bus Nacos支持AP和CP的切换。 来源： oschina 链接： https://my.oschina.net/u/4305000/blog/4355288

前言 上篇文章《Spring Cloud Gateway 限流操作》我讲过复杂的限流场景可以通过扩展RedisRateLimiter来实现自己的限流策略。 假设你领导给你安排了一个任务，具体需求如下： • 针对具体的接口做限流 • 不同接口限流的力度可以不同 • 可以动态调整限流配置，实时生效 如果你接到上面的任务，你会怎么去设计+实现呢？ 每个人看待问题的角度不同，自然思考出来的方案也不同，正所谓条条大路通罗马，能到达亩的地的路那就是一条好路。 如何分析需求 下面我给出我的实现方式，仅供各位参考，大牛请忽略。 具体问题具体分析，针对需求点，分别去做分析。 需求一 “如何针对具体的接口做限流” 这个在上篇文章中也有讲过，只需要让KeyResolver返回的是接口的URI即可，这样限流的维度那就是对这个接口进行限流。 需求二 “不同接口限流的力度可以不同” 这个通过配置的方式明显实现不了，配置中的replenishRate和burstCapacity都是配置死的，如果要做成动态的那么必须的自己通过扩展RedisRateLimiter来实现。 前提是必须有一个配置列表，这个配置列表就是每个接口对应的限流数值。有了这个配置我们就可以通过请求的接口获取这个接口对应的限流值。 需求三“可以动态调整限流配置，实时生效” 这个的话也比较容易，无论你是存文件，存数据库，存缓存只要每次都去读取

1. zipkin基础介绍: 分布式追踪系统 概念： tranceID: 请求全局处理标识 spanID: 请求在单个服务流转处理标识 ParentID: 子服务中显示父服务ID(spanID)，主要用于构建服务调用链路 数据传输到Zipkin方式： http kafka Scribe Zipkin构成组件： collector: zipkin校验、保存、索引接收的追踪数据 storage: zipkin 数据存储（Cassandra、mysql、ES、内存等，支持扩展） search: zipkin 数据检索服务（WEB UI） WEB UI: 数据追踪展示UI,默认没有认证 2. 环境部署 参考官网下载： zipkin quickstart 3. 使用案例 3.1 maven 依赖引入 <dependencies> <dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-starter-netflix-eureka-client</artifactId> </dependency> <dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-starter

作者：miracle1919 http://www.importnew.com/10780.html McGovernTheory在StackOverflow提了这样一个问题： Java虚拟机最多支持多少个线程？跟虚拟机开发商有关么？跟操作系统呢？还有其他的因素吗？ Eddie的回答: 这取决于你使用的CPU，操作系统，其他进程正在做的事情，你使用的Java的版本，还有其他的因素。我曾经见过一台Windows服务器在宕机之前有超过6500个线程。当然，大多数线程什么事情也没有做。一旦一台机器上有差不多6500个线程（Java里面），机器就会开始出问题，并变得不稳定。 以我的经验来看，JVM容纳的线程与计算机本身性能是正相关的。 当然了，你要有足够的本机内存，并且给Java分配了足够的内存，让每个线程都可以拥有栈(虚拟机栈)，可以做任何想做的事情。任何一台拥有现代CPU（AMD或者是Intel最近的几代）和1-2G内存（取决于操作系统）的机器很容易就可以支持有上千个线程的Java虚拟机。 如果你需要一个更精确的答案，最好是自己做压测。 Charlie Martin的回答: 这里有很多的参数（可以设置）。对于特定的虚拟机，都会有自己的运行时参数。（最大线程数）一定程度上由操作系统决定的：底层的操作系统要给线程提供哪些支持？施加哪些限制？虚拟机使用的是原生的操作系统的线程还是red

全网唯一开源核心代码的交易所，架构/代码质量看得见 我想这可能是你搭建交易所，或者二次开发的最好选择 特色1: 基于内存撮合引擎，与传统基于数据库撮合更快 特色2: 前后端分离，基于Token的Api授权机制 特色3: 基于SpringCloud微服务架构，扩展更容易 特色4: MySQL、MongoDB、Redis多种数据存储方式，只为更快 特色5: Kafka发布订阅消息队列，让订单更快流转 特色6: 主流币种对接区块链接口齐全，开箱即用 特色7: 冷热钱包分离，两种提现方式，保证安全 特色8: 机器人系统，同步行情，维护深度，防止搬砖 特色9: 原生App，Java和ObjectC提供原生体验 特色10: 交易所设计者提供技术支持，部署+二开无忧 特色11: 支持添加自定义平台币及其他币种 声明一：我已在新公司上班，一些说明性的东西我会抽空在这里更新，以方便大家编译、搭建、开发 声明二：部分源码未开源（有偿提供），有需要的添加QQ：615745258 声明三：请注意，本源码唯一交易渠道为QQ：615745258，没有其他QQ或微信，谨防被骗！！！ 声明四：请不要用本开源代码直接搭建交易所！本源码尚有一些隐藏BUG，仅供学习！否则后果自负！ 声明五：本交易所完整源码仅向有技术团队或技术实力的人提供，小白或不同技术的请勿咨询！ 简要介绍 本项目是基于Java