2017

消息场景:用户 A 发送一个消息给用户 B,用户 B 回复一个消息给用户 A。。。 现有设计:消息设计为实体并为聚合根,发件人、收件人设计为值对象。 三个问题: 实体最重要的特性是什么? Message 实体是怎么得来的? 发件人、收件人为什么不是实体? 1. 实体最重要的特性是什么?《领域驱动设计》5.2 实体: 摘录一段:许多对象不是由它们的属性来定义,而是通过一系列的连续性(continuity)和标识(identity)来从根本上定义的。 归纳: 标识(identity) 连续性(continuity) 标识在实体中的另一种体现就是唯一和不可变,其概念在很多资料中有说明,这也是实体最重要的特性。 我有一个双胞胎哥哥,我们俩出生的时候,长得一模一样,以至于我们的爸妈都分不清,不得已他们在我们脖子上系个项链来标记:谁是老大?谁是老二?其实这个“标记”就可以看作是实体的...

做一枚全栈工程师 如果一个全栈工程师能够根据原型实现一个完整的MVP(minimum viable product,至少可行的产品),我们通常会认为他十八般武艺样样精通,而且有足够的理由来证明这一点。为了给全栈工程师一个最新鲜的定义,我们首先来关注一下全栈工程师以前是搞什么的。 以前的全栈工程师很久以前,大约在 2000 年(在互联网的次元里,17年可以说是一个非常长的时间了),一个全栈工程师必须掌握下面的本领: 用 Adobe 公司的 Photoshop 或者 Fireworks 工具设计出一个网页 将设计稿变成 HTML, CSS 还有热点图(额,还记得那些吗?) 写一些基本的 PHP 4.0 脚本(非面向对象的 PHP 即将成为历史)来处理服务端逻辑 保存所有的动态数据到 MySQL 中,也可能会做一些小优化 用 FTP 上传所有代码、数据库什么的到一台服务器,然后...

HelloPWS(Pivotal Web Service),由 Pivotal 公司提供的 ,可以运行Java, Grails, Play, Spring, Node.js, Ruby on Rails, Sinatra or Go 等Web应用的服务。本文将介绍一个 Hello World 级别的 Spring Boot 应用发布到 PWS 的过程。 武器 CentOS 7.3 OpenJDK 1.8.0_141 Maven 3.0.5 准备战斗1、在 https://run.pivotal.io/ 注册一个账号,完成手机绑定。 2、在 Github 上克隆一个 Spring Boot 的 hello world 的项目。 git clone https://github.com/spring-guides/gs-spring-boot.git 好戏开场1、安装 cf CLI ...

通过之前几篇Spring Cloud中几个核心组件的介绍,我们已经可以构建一个简略的(不够完善)微服务架构了。比如下图所示: 我们使用Spring Cloud Netflix中的Eureka实现了服务注册中心以及服务注册与发现;而服务间通过Ribbon或Feign实现服务的消费以及均衡负载;通过Spring Cloud Config实现了应用多环境的外部化配置以及版本管理。为了使得服务集群更为健壮,使用Hystrix的融断机制来避免在微服务架构中个别服务出现异常时引起的故障蔓延。 在该架构中,我们的服务集群包含:内部服务Service A和Service B,他们都会注册与订阅服务至Eureka Server,而Open Service是一个对外的服务,通过均衡负载公开至服务调用方。本文我们把焦点聚集在对外服务这块,这样的实现是否合理,或者是否有更好的实现方式呢? 先来说说这样架构...

REST围绕着资源这个概念而构建的,然后用URI来表示。然后一个HTTP动词和资源URI组合起来对指定资源进行HTTP调用来执行操作。大多数REST框架提供了指定资源名称的生成器,框架围绕着它来生成脚手架。不幸的是,许多这些生成器使用CRUD模型(Create,Read, Update, Delete)作为默认的起始点。资源被定义为一系列的属性,使用类似JSON Schema或某个具体语言的数据对象来定义,然后生成方法存根,然后来创建,读取,更新和删除该资源。 尽管这可以让开发人员觉得理解和开始工作变得简单了许多,是一个很好的起点,但是使用CRUD作为API的起点,我有一个很大的疑问。就是CRUD中的U是我最不喜欢的。让我们来谈谈U.通用更新方法允许客户端更新资源的任何字段,然后使用新版本覆盖现有版本。但是,如果允许客户端执行这样的操作,您的服务API在其使用的任何底层数据存储之上,...

简介该项目主要利用Spring Boot的自动化配置特性来实现快速的将swagger2引入spring boot应用来生成API文档,简化原生使用swagger2的整合代码。 GitHub:https://github.com/dyc87112/spring-boot-starter-swagger 码云:http://git.oschina.net/didispace/spring-boot-starter-swagger 博客:http://blog.didispace.com 小工具一枚,欢迎使用和Star支持,如使用过程中碰到问题,可以提出Issue,我会尽力完善该Starter 版本基础 Spring Boot:1.5.x Swagger:2.7.x 如何使用在该项目的帮助下,我们的Spring Boot可以轻松的引入swagger2,主需要做下面两个步骤: 在po...

我以前写过一篇关于领域事件的文章——实现领域事件,随着在项目中深入的使用DDD架构,我对领域事件有了新的认识。尤其是采用领域事件来解耦代码这种方式对项目的发展具有深远的影响。 我在实现领域事件中主要谈到了如何在技术层面去实现发布事件与订阅事件,比较了几种不同的方式以及它们背后的原理。但随着我在自己负责的项目中严格地实施DDD架构时,我发现如何去发布订阅领域事件的意义远没有决定去做这件事情本身重要。换句话说,与其纠结与是使用基于Spring的事件架构还是Guava提供的EventBus,是使用同步发布还是异步发布,还不如想想去做这件事情对你的项目会产生怎样的影响。 为什么要使用事件?我认为这是所有人应该考虑的首要问题。对我来说,使用事件的意义有两个方面,一是在于流程上的解耦,二是在于代码层面的解耦。在代码层面的解耦是显而易见的,我就不再赘述了。那么流程上的解耦是什么意思了?我们先看一下...

当你的系统或者业务变得日益复杂时,DDD的模式是一种非常值得尝试的架构模式。DDD让你更加关注于你的业务领域,思考你的业务模型,帮组你理清繁杂的业务关系。我推荐所有还没有了解过或者接触过DDD的后端工程师都去学习一下该架构模式。本文主要关注DDD中的领域事件,以及一种可能的实践方式。 我们知道领域模型的变化会产生领域事件。例如,用户在完成注册后,系统会发出一封带有确认信息的邮件到用户的邮箱;用户关注的好友发送动态后他会收到相应的通知等等。在业务比较简单或者不用考虑性能的情况下,我们可以直接把对领域事件的处理嵌入到领域服务中。考虑这样一个场景:用户回复了某条评论,那么被回复的那个用户(也就是那条评论的所有者)需要收到一个PUSH消息。这个场景比较简单,我们可能直接写出类似下面的代码: void reply(long fromUserId,long toUserId,String ...

相信有很多童鞋跟我一样,热衷于用Markdown来编写文章。由于其简单的语法和清晰的渲染效果,受到广大码农朋友们的推崇。但是,当我们想维护起自己的公众号时,公众号编辑器往往让我们费劲了脑汁。本人尝试了各种工具,比如:秀米一些在线提供多种不同样式的编辑器。虽然这些编辑器都能够完成编辑任务,但是效果并不理想。与我们所追求的简洁、清晰风格总是格格不入,尤其是对于代码的展示非常的不友好。所以,这里给大家推荐一个本站的在线工具,可以帮助大家快速地把Markdown文章转换成微信公众号支持的漂亮格式。 首先奉上本文即将介绍的工具地址:http://blog.didispace.com/tools/online-markdown/ 最新版本:http://md.openwrite.cn/ 全新的用户体验,已远优于下面的介绍,建议直接进入体验! 使用方法该工具的使用非常非常简单,点击http:/...

关于领域驱动设计这篇文章参考了Eric Evans《领域驱动设计》一书以及Jimmy Nilsson《以C# .NET为例运用领域驱动设计和模式》,二者详细描述了领域驱动设计的核心概念、技术和模式。在某些情况下,直接使用这些书的措辞是有意义的,并且我认为Eric Evans和Jimmy Nilsson也允许我们这么做。 尽管将方法本身呈现出来是很有用的,但是仅仅对方法进行描述,DDD的许多微妙之处就会消失。这些方法应该是你的工具,而不是你束缚你的规则。它们是为设计而生的语言,在团队内沟通创意和模型十分有益。更为重要的是,记住实践DDD的目的是为了做出更加务实的决定。不要试图将一个方法强加于一个模型。另外,如果你“打破”了一个方法,确保你已经理解了这么做的理由,并将其与其他人沟通。 通常认为,DDD在面向对象范式下表现良好,但远不止这些。DDD解决了如何去理解问题空间这一挑战,甚至是更...

前言 在一个高并发系统中对流量的把控是非常重要的,当巨大的流量直接请求到我们的服务器上没多久就可能造成接口不可用,不处理的话甚至会造成整个应用不可用。 比如最近就有个这样的需求,我作为客户端要向kafka生产数据,而kafka的消费者则再源源不断的消费数据,并将消费的数据全部请求到web服务器,虽说做了负载(有4台web服务器)但业务数据的量也是巨大的,每秒钟可能有上万条数据产生。如果生产者直接生产数据的话极有可能把web服务器拖垮。 对此就必须要做限流处理,每秒钟生产一定限额的数据到kafka,这样就能极大程度的保证web的正常运转。 其实不管处理何种场景,本质都是降低流量保证应用的高可用。 常见算法对于限流常见有两种算法: 漏桶算法 令牌桶算法 漏桶算法比较简单,就是将流量放入桶中,漏桶同时也按照一定的速率流出,如果流量过快的话就会溢出(漏桶并不会提高流出速率)。溢出的流量...

问题描述在之前发布的《Spring Cloud实战小贴士:Feign的继承特性(伪RPC模式)》一文中,我们介绍了如果使用Feign的继承特性来完成服务的提供以及服务的消费,实现了类似RPC的编程模式。但是,仔细一些的读者可能已经发现一个问题:当我们将服务消费者运行起来的时候,定义在服务提供方的那些请求映射关系也被加载到了服务消费者中,这就会带来两个问题: 由于服务消费者并不提供这些接口,对于开发者来说容易造成误解 由于加载了一些外部服务的接口定义,还存在与自身接口定义冲突的潜在风险 问题分析那么这些外部请求接口定义是如何被加载到消费端的呢?我们先来看看Spring MVC处理请求映射的RequestMappingHandlerMapping实现片段: @Overrideprotected boolean isHandler(Class<?> beanType) &#...

上一篇文章中我们介绍了获取token的流程,这一篇重点分析一下,携带token访问受限资源时,内部的工作流程。 @EnableResourceServer与@EnableAuthorizationServer还记得我们在第一节中就介绍过了OAuth2的两个核心概念,资源服务器与身份认证服务器。我们对两个注解进行配置的同时,到底触发了内部的什么相关配置呢? 上一篇文章重点介绍的其实是与身份认证相关的流程,即如果获取token,而本节要分析的携带token访问受限资源,自然便是与@EnableResourceServer相关的资源服务器配置了。 我们注意到其相关配置类是ResourceServerConfigurer,内部关联了ResourceServerSecurityConfigurer和HttpSecurity。前者与资源安全配置相关,后者与http安全配置相关。(类名比较类似,注...

本文开始从源码的层面,讲解一些spring Security Oauth2的认证流程。本文较长,适合在空余时间段观看。且涉及了较多的源码,非关键性代码以…代替。 获取token上一篇博客中我们尝试使用了password模式和client模式,有一个比较关键的endpoint:/oauth/token。从这个入口开始分析,spring security oauth2内部是如何生成token的。 首先开启debug信息: logging: level: org.springframework: DEBUG 可以完整的看到内部的运转流程。 client模式稍微简单一些,使用client模式获取tokenhttp://localhost:8080/oauth/token? client_id=client_1&client_secret=123456&scope=se...

前言今天来聊聊一个接口对接的场景,A厂家有一套HTTP接口需要提供给B厂家使用,由于是外网环境,所以需要有一套安全机制保障,这个时候oauth2就可以作为一个方案。 关于oauth2,其实是一个规范,本文重点讲解spring对他进行的实现,如果你还不清楚授权服务器,资源服务器,认证授权等基础概念,可以移步理解OAuth 2.0 - 阮一峰,这是一篇对于oauth2很好的科普文章。 需要对spring security有一定的配置使用经验,用户认证这一块,spring security oauth2建立在spring security的基础之上。第一篇文章主要是讲解使用springboot搭建一个简易的授权,资源服务器,在文末会给出具体代码的github地址。后续文章会进行spring security oauth2的相关源码分析。Java中的安全框架如shrio,已经有跟我学shir...