上一篇文章《Spring Security(二)–Guides》，通过Spring Security的配置项了解了Spring Security是如何保护我们的应用的，本篇文章对上一次的配置做一个分析。 3 核心配置解读3.1 功能介绍这是Spring Security入门指南中的配置项： @Configuration@EnableWebSecuritypublic class WebSecurityConfig extends WebSecurityConfigurerAdapter { @Override protected void configure(HttpSecurity http) throws Exception { http .authorizeRequests() .antMatcher...

上一篇文章《Spring Security(一)–Architecture Overview》，我们介绍了Spring Security的基础架构，这一节我们通过Spring官方给出的一个guides例子，来了解Spring Security是如何保护我们的应用的，之后会对进行一个解读。 2 Spring Security Guides2.1 引入依赖<dependencies> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-web</artifactId> </dependency> <dependency> ...

一直以来我都想写一写Spring Security系列的文章，但是整个Spring Security体系强大却又繁杂。陆陆续续从最开始的guides接触它，到项目中看了一些源码，到最近这个月为了写一写这个系列的文章，阅读了好几遍文档，最终打算尝试一下，写一个较为完整的系列文章。 较为简单或者体量较小的技术，完全可以参考着demo直接上手，但系统的学习一门技术则不然。以我的认知，一般的文档大致有两种风格：Architecture First和Code First。前者致力于让读者先了解整体的架构，方便我们对自己的认知有一个宏观的把控，而后者以特定的demo配合讲解，可以让读者在解决问题的过程中顺便掌握一门技术。关注过我博客或者公众号的朋友会发现，我之前介绍技术的文章，大多数是Code First，提出一个需求，介绍一个思路，解决一个问题，分析一下源码，大多如此。而学习一个体系的技术，我...

本文非技术分享，仅仅是今日的一点感慨，为国内不尊重原创作者的行为表示遗憾~！！！ 我是公众号“程序猿DD”的维护者，博客didispace.com的博主，《Spring Cloud微服务实战》的作者，也是spring4all社区的发起人之一。由于本人一直在研究Spring Cloud相关的技术点，也有幸出了书，获得了一些Spring Cloud爱好者的支持，对于朋友圈转发的类似内容一直都报有极大兴趣。一直以来，很多高质量公众号都推送过大量优秀的关于Spring Cloud的好文章，我也从中学习到很多知识。但是今天看到来自普元EAWorld公号中发布的《最简单易懂的SpringCloudSleuth教程》一文，就觉得怎么就那么似曾相识呢… 传送门：《最简单易懂的SpringCloudSleuth教程》 打开文章，大家可以很清晰的看到声明了【原创】标示，同时很牛逼的宣称：转载须注明出处，...

上一篇我们介绍了如何使用Ribbon的earger-load配置加速Spring Cloud中对服务接口的第一次调用。可是这样只是解决了内部服务间的调用，另外一个问题依然经常困扰我们，那就是网关到内部服务的访问。由于Spring Cloud Zuul的路由转发也是通过Ribbon实现负载均衡的，所以它也会存在第一次调时比较慢的情况。那么这个时候我们要如何设置呢？ Zuul中的Eager Load配置在Spring Cloud Zuul中也提供了一个配置参数来实现earger-load，具体如下： zuul.ribbon.eager-load.enabled=true 但是，可能你尝试一下之后会发现，并没有起效？为什么呢？这是由于Spring Cloud Zuul中实现eager-load的时候同Ribbon中一样，都需要指定具体哪些服务需要饥饿加载。那么在Spring Cloud...

前文导读：《都在说微服务，那么微服务的反模式和陷阱是什么（一）》《都在说微服务，那么微服务的反模式和陷阱是什么（二）》 九、通信协议使用的陷阱在微服务架构体系中要求每个服务都是独立布署，这就意味着服务之间会有通信，也就是说会有很多的远程访问。 当你不知道这些远程访问需要多长时间的时候，就会掉入到这个陷阱，当然我们可以假定远程访问一次50毫秒，但我们是否真正的进行过测试呢？那么服务的平均响应时间是多少呢？即使有看上去很好的平均响应时间，那么糟糕的“长尾延迟”也会将整体系统摧毁。 9.1 延迟测量在生产环境中进行压力测试，是检测我们系统性能的重要手段之一，举个例子：我们有一个特定业务需要四个服务来协调处理，假如远程访问一次的时间是100毫秒，那么这个特定业务就需要消耗500毫秒（初始请求+四个服务的调用时间），这个只是远程访问的时间，还不算实际业务代码的执行时间，这是大多数应用系统都...

上一篇：《都在说微服务，那么微服务的反模式和陷阱是什么（一）》 六、无因的开发者陷阱名字来自詹姆斯·迪恩演的电影《无因的反叛》（Rebel Without a Cause），一个问题青年因为错误的原因做了错误的决定。 很多架构师和开发者在微服务的开发中权衡利弊， 比如服务粒度和运维工具，但是基于错误的原因，做了错误的决定。 6.1 做出错误的决定图6-1说明了一种情况是通过测试发现服务划分的太细了，因此非常影响性能，主要是由于服务划分的太细导致增加了通信工作量也在一定程度上对稳定性造成一定影响。在这种情况下，开发人员或架构师决定将这些服务整合到一个更粗粒度的服务中，以解决性能和可靠性问题。 这个方案看起来似乎合情合理，但是之后的布署、更改控制和测试都会受到影响。 再看图6-2，这种场景是左边的服务太粗了，影响了服务的测试和布署，于是进行了拆分，减少了每个服务的范围。 通过以上...

一、数据驱动的迁移反模式微服务会创建大量小的、分布式的、单一用途的服务，每个服务拥有自己的数据。这种服务和数据耦合支持一个有界的上下文和一个无共享数据的架构，其中，每个服务及其对应的数据是独立一块，完全独立于所有其他服务。服务只暴露了一个明确的接口（服务契约）。有界的上下文可以允许开发者以最小的依赖快速轻松地开发，测试和部署。 采用数据驱动迁移反模式主要发生在当你从一个单体应用向微服务架构做迁移的时候。我们之所以称之为反模式主要原因是，刚开始我们觉得创建微服务是一个不错的主意，服务和相应的数据都独立成微服务，但这可能会将你带向一个错误的道路上，导致高风险、过剩成本和额外的迁移工作。 单体应用迁移到微服务架构有两个主要目标： 第一个目标是单体应用程序的功能分割成小的，单一用途的服务。 第二个目标是单体应用的数据迁移到每个服务自己独占的小数据库（或独立的服务）。 下图展示了一个典型的...

我们在使用Spring Cloud的Ribbon或Feign来实现服务调用的时候，如果我们的机器或网络环境等原因不是很好的话，有时候会发现这样一个问题：我们服务消费方调用服务提供方接口的时候，第一次请求经常会超时，而之后的调用就没有问题了。下面我们就来说说造成这个问题的原因，以及如何解决的方法。 问题原因造成第一次服务调用出现失败的原因主要是Ribbon进行客户端负载均衡的Client并不是在服务启动的时候就初始化好的，而是在调用的时候才会去创建相应的Client，所以第一次调用的耗时不仅仅包含发送HTTP请求的时间，还包含了创建RibbonClient的时间，这样一来如果创建时间速度较慢，同时设置的超时时间又比较短的话，很容易就会出现上面所描述的显现。 从日志中我们也能知道这一点细节，在第一次发起调用的时候我们可以从日志中看到如下信息： 2017-09-25 08:29:54,...

导读: 程序员你为什么这么累？ 我的编码习惯 - 接口定义 我的编码习惯 - Controller规范 我的编码习惯 - 日志建议 我的编码习惯 - 异常处理 我的编码习惯 - 参数校验和国际化规范 我的编码习惯 - 工具类规范 我的编码习惯 - 函数编写建议 我的编码习惯 - 配置规范 之前系列文章里面完整的代码已经上github，地址在文章最后 傻瓜都能写出计算机可以读懂的代码，只有优秀的程序员才能写出人能读懂的代码！ 在我看来，编写简单的函数是一件简单又困难的事情。简单是因为这没有什么技术难点，困难是因为这是一种思维习惯，很难养成，不写个几年代码，很难写出像样的代码。 大部分的程序员写的都是CRUD、一些业务逻辑的代码，谁实现不了？对于我来说，如果业务逻辑的代码评审，需要人来讲每一个代码做了什么，这样的代码就是不合格的，合格的代码写出来应该像人说话那么简单有条理，基本上...

导读: 程序员你为什么这么累？ 我的编码习惯 - 接口定义 我的编码习惯 - Controller规范 我的编码习惯 - 日志建议 我的编码习惯 - 异常处理 我的编码习惯 - 参数校验和国际化规范 我的编码习惯 - 工具类规范 我的编码习惯 - 函数编写建议 我的编码习惯 - 配置规范 前些时间写了很多编码习惯的帖子，今天写一点简单的技术贴。其实我个人觉得编码习惯是最主要的，比技术重要，但初学者还是喜欢看技术贴，今天就写一个小Demo，也加深自己的理解。 JDK的动态代理是非常重要的技术，使用的地方很多，用于代理接口，Spring的AOP也会用到。技术细节这里不贴了，我不是技术高手，大家可以上网搜索一下一大把，今天我们结合spring编写一个简陋的“框架”。 完整代码已经上传到GITHUB，地址在最后面。 最终效果假设我们需要调用另外一个系统提供了的GET请求 http://l...

在整体应用架构中，非生产环境情况下，一般 1GB 或者 2GB 的 RAM 就足够了。如果我们将这个应用程序划分为 20 或 30 个独立的微服务，那么很难期望 RAM 仍将保持在 1GB 或 2GB 左右。特别是如果我们使用 Spring Cloud 的时候。 首先，准备三个服务，Eureka 服务 + 提供 REST API 的两个简单的微服务，并将微服务注册到 Eureka。此处，不以任何方式限制这些应用程序的内存使用。 提示：Spring Cloud 简单应用的搭建示例：https://www.ictgu.cn/share/6644e468 就像你在下图看到的一样，三个微服务大概占用了电脑 1.5GB 的 RAM 内存。这三个服务是最简单的应用程序，基本没有数据处理量，对于这样的内存消耗量，显然是不理想的。RAM 的最低使用量是用于 Eureka发现服务，最大的用于初始...

IoC 控制反转(Inversion of Control)是OOP中的一种设计原则,也是Spring框架的核心.大多数应用程序的业务逻辑代码都需要两个或多个类进行合作完成的,通过IoC则可以减少它们之间的耦合度. 实现方法 IoC的主要实现方法有两种,依赖注入与依赖查找. 依赖注入 : 应用程序被动的接收对象,IoC容器通过类型或名称等信息来判断将不同的对象注入到不同的属性中. 依赖注入主要有以下的方式: 基于set方法 : 实现特定属性的public set()方法,来让IoC容器调用注入所依赖类型的对象. 基于接口 : 实现特定接口以供IoC容器注入所依赖类型的对象. 基于构造函数 : 实现特定参数的构造函数,在创建对象时来让IoC容器注入所依赖类型的对象. 基于注解 : 通过Java的注解机制来让IoC容器注入所依赖类型的对象,例如Spring框架中的@Autowi...

概述微服务架构是一种非常流行的新概念，即便可供以借鉴的经验比较少，当然不能阻挡它成为热门话题与研究对象。 令人惊讶地是，其实微服务的概念早在五十多年前就已经被提出，多年来，很久研究表明了这些观点的准确性。这就是本文所介绍的——康威定律。现在已经有很多企业正在尝试使用它创建高效的微服务架构。 在这篇文章中最有名的一句话莫过于： 设计系统的企业受限于生产设计，这些设计是企业沟通结构的副本——Melvin Conway(1967)。 这意味着设计系统的企业，它们生产的设计等同于企业内的沟通结构。下图说明了此概念： 该图展现了企业现有沟通结构，简单地说：企业结构等于系统设计。 作者这里提到的系统并不局限于应用系统，据说这篇文章最初投稿于哈佛商业评论，但被拒绝，因此康威将其提交到了一个编程杂志，所以被误解为只针对应用开发，起初，作者并没有把这种理论作为定律，只是描述了发现和结论，不过著名的...

导读: 程序员你为什么这么累？ 我的编码习惯 - 接口定义 我的编码习惯 - Controller规范 我的编码习惯 - 日志建议 我的编码习惯 - 异常处理 我的编码习惯 - 参数校验和国际化规范 我的编码习惯 - 工具类规范 我的编码习惯 - 函数编写建议 我的编码习惯 - 配置规范 请先仔细阅读：分享我工作中制定配置文件的习惯 工作中少不了要制定各种各样的配置文件，这里和大家分享一下工作中我是如何制定配置文件的，这是个人习惯，结合强大的spring，效果很不错。 =============================需求========================== 如我们现在有一个这样的配置需求，顶层是Server，有port和shutdown2个属性，包含一个service集合，service对象有name一个属性，并包含一个connector集合，conne...