#
最近几年，在DDD的领域，我们经常会看到CQRS架构的概念。我个人也写了一个ENode框架，专门用来实现这个架构。CQRS架构本身的思想其实非常简单，就是读写分离。是一个很好理解的思想。就像我们用MySQL数据库的主备，数据写到主，然后查询从备来查，主备数据的同步由MySQL数据库自己负责，这是一种数据库层面的读写分离。关于CQRS架构的介绍其实已经非常多了，大家可以自行百度或google。我今天主要想总结一下这个架构相对于传统架构（三层架构、DDD经典四层架构）在数据一致性、扩展性、可用性、伸缩性、性能这几个方面的异同，希望可以总结出一些优点和缺点，为大家在做架构选型时提供参考。
前言
CQRS架构由于本身只是一个读写分离的思想，实现方式多种多样。比如数据存储不分离，仅仅只是代码层面读写分离，也是CQRS的体现；然后数据存储的读写分离，C端负责数据存储，Q端负责数据查询，Q端的数据通过C端产生的Event来同步，这种也是CQRS架构的一种实现。今天我讨论的CQRS架构就是指这种实现。另外很重要的一点，C端我们还会引入Event Sourcing+In Memory这两种架构思想，我认为这两种思想和CQRS架构可以完美的结合，发挥CQRS这个架构的最大价值。
数据一致性
传统架构，数据一般是强一致性的，我们通常会使用数据库事务保证一次操作的所有数据修改都在一个数据库事务里，从而保证了数据的强一致性。在分布式的场景，我们也同样希望数据的强一致性，就是使用分布式事务。但是众所周知，分布式事务的难度、成本是非常高的，而且采用分布式事务的系统的吞吐量都会比较低，系统的可用性也会比较低。所以，很多时候，我们也会放弃数据的强一致性，而采用最终一致性；从CAP定理的角度来说，就是放弃一致性，选择可用性。
CQRS架构，则完全秉持最终一致性的理念。这种架构基于一个很重要的假设，就是用户看到的数据总是旧的。对于一个多用户操作的系统，这种现象很普遍。比如秒杀的场景，当你下单前，也许界面上你看到的商品数量是有的，但是当你下单的时候，系统提示商品卖完了。其实我们只要仔细想想，也确实如此。因为我们在界面上看到的数据是从数据库取出来的，一旦显示到界面上，就不会变了。但是很可能其他人已经修改了数据库中的数据。这种现象在大部分系统中，尤其是高并发的WEB系统，尤其常见。
所以，基于这样的假设，我们知道，即便我们的系统做到了数据的强一致性，用户还是很可能会看到旧的数据。所以，这就给我们设计架构提供了一个新的思路。我们能否这样做：我们只需要确保系统的一切添加、删除、修改操作所基于的数据是最新的，而查询的数据不必是最新的。这样就很自然的引出了CQRS架构了。C端数据保持最新、做到数据强一致；Q端数据不必最新，通过C端的事件异步更新即可。所以，基于这个思路，我们开始思考，如何具体的去实现CQ两端。看到这里，也许你还有一个疑问，就是为何C端的数据是必须要最新的？这个其实很容易理解，因为你要修改数据，那你可能会有一些修改的业务规则判断，如果你基于的数据不是最新的，那意味着判断就失去意义或者说不准确，所以基于老的数据所做的修改是没有意义的。
扩展性
传统架构，各个组件之间是强依赖，都是对象之间直接方法调用；而CQRS架构，则是事件驱动的思想；从微观的聚合根层面，传统架构是应用层通过过程式的代码协调多个聚合根一次性以事务的方式完成整个业务操作。而CQRS架构，则是以Saga的思想，通过事件驱动的方式，最终实现多个聚合根的交互。另外，CQRS架构的CQ两端也是通过事件的方式异步进行数据同步，也是事件驱动的一种体现。上升到架构层面，那前者就是SOA的思想，后者是EDA的思想。SOA是一个服务调用另一个服务完成服务之间的交互，服务之间紧耦合；EDA是一个组件订阅另一个组件的事件消息，根据事件信息更新组件自己的状态，所以EDA架构，每个组件都不会依赖其他的组件；组件之间仅仅通过topic产生关联，耦合性非常低。
上面说了两种架构的耦合性，显而易见，耦合性低的架构，扩展性必然好。因为SOA的思路，当我要加一个新功能时，需要修改原来的代码；比如原来A服务调用了B,C两个服务，后来我们想多调用一个服务D，则需要改A服务的逻辑；而EDA架构，我们不需要动现有的代码，原来有B,C两订阅者订阅A产生的消息，现在只需要增加一个新的消息订阅者D即可。
从CQRS的角度来说，也有一个非常明显的例子，就是Q端的扩展性。假设我们原来Q端只是使用数据库实现的，但是后来系统的访问量增大，数据库的更新太慢或者满足不了高并发的查询了，所以我们希望增加缓存来应对高并发的查询。那对CQRS架构来说很容易，我们只需要增加一个新的事件订阅者，用来更新缓存即可。应该说，我们可以随时方便的增加Q端的数据存储类型。数据库、缓存、搜索引擎、NoSQL、日志，等等。我们可以根据自己的业务场景，选择合适的Q端数据存储，实现快速查询的目的。这一切都归功于我们C端记录了所有模型变化的事件，当我们要增加一种新的View存储时，可以根据这些事件得到View存储的最新状态。这种扩展性在传统架构下是很难做到的。
可用性
可用性，无论是传统架构还是CQRS架构，都可以做到高可用，只要我们做到让我们的系统中每个节点都无单点即可。但是，相比之下，我觉得CQRS架构在可用性方面，我们可以有更多的回避余地和选择空间。
传统架构，因为读写没有分离，所以可用性要把读写合在一起综合考虑，难度会比较更大。因为传统架构，如果一个系统的高峰期的并发写入很大，比如为2W，并发读取也很大，比如为10W。那该系统必须优化到能同时支持这种高并发的写入和查询，否则系统就会在高峰时挂掉。这个就是基于同步调用思路的系统的缺点，没有一个东西去削峰填谷，保存瞬间多出来的请求，而必须让系统不管遇到多少请求，都必须能及时处理完，否则就会造成雪崩效应，造成系统瘫痪。但是一个系统，不会一直处在高峰，高峰可能只有半小时或1小时；但为了确保高峰时系统不挂掉，我们必须使用足够的硬件去支撑这个高峰。而大部分时候，都不需要这么高的硬件资源，所以会造成资源的浪费。所以，我们说基于同步调用、SOA思想的系统的实现成本是非常昂贵的。
而在CQRS架构下，因为CQRS架构把读和写分离了，所以可用性相当于被隔离在了两个部分去考虑。我们只需要考虑C端如何解决写的可用性，Q端如何解决读的可用性即可。C端解决可用性，我觉得是更加容易的，因为C端是消息驱动的。我们要做任何数据修改时，都会发送Command到分布式消息队列，然后后端消费者处理Command->产生领域事件->持久化事件->发布事件到分布式消息队列->最后事件被Q端消费。这个链路是消息驱动的。相比传统架构的直接服务方法调用，可用性要高很多。因为就算我们处理Command的后端消费者暂时挂了，也不会影响前端Controller发送Command，Controller依然可用。从这个角度来说，CQRS架构在数据修改上可用性要更高。不过你可能会说，要是分布式消息队列挂了呢？呵呵，对，这确实也是有可能的。但是一般分布式消息队列属于中间件，一般中间件都具有很高的可用性（支持集群和主备切换），所以相比我们的应用来说，可用性要高很多。另外，因为命令是先发送到分布式消息队列，这样就能充分利用分布式消息队列的优势：异步化、拉模式、削峰填谷、基于队列的水平扩展。这些特性可以保证即便前端Controller在高峰时瞬间发送大量的Command过来，也不会导致后端处理Command的应用挂掉，因为我们是根据自己的消费能力拉取Command。这点也是CQRS C端在可用性方面的优势，其实本质也是分布式消息队列带来的优势。所以，从这里我们可以体会到EDA架构（事件驱动架构）是非常有价值的，这个架构也体现了我们目前比较流行的Reactive Programming（响应式编程）的思想。
然后，对于Q端，应该说和传统架构没什么区别，因为都是要处理高并发的查询。这点以前怎么优化的，现在还是怎么优化。但是就像我上面可扩展性里强调的，CQRS架构可以更方便的提供更多的View存储，数据库、缓存、搜索引擎、NoSQL，而且这些存储的更新完全可以并行进行，互相不会拖累。理想的场景，我觉得应该是，如果你的应用要实现全文索引这种复杂查询，那可以在Q端使用搜索引擎，比如ElasticSearch；如果你的查询场景可以通过keyvalue这种数据结构满足，那我们可以在Q端使用Redis这种NoSql分布式缓存。总之，我认为CQRS架构，我们解决查询问题会比传统架构更加容易，因为我们选择更多了。但是你可能会说，我的场景只能用关系型数据库解决，且查询的并发也是非常高。那没办法了，唯一的办法就是分散查询IO，我们对数据库做分库分表，以及对数据库做一主多备，查询走备机。这点上，解决思路就是和传统架构一样了。
性能、伸缩性
本来想把性能和伸缩性分开写的，但是想想这两个其实有一定的关联，所以决定放在一起写。
伸缩性的意思是，当一个系统，在100人访问时，性能（吞吐量、响应时间）很不错，在100W人访问时性能也同样不错，这就是伸缩性。100人访问和100W人访问，对系统的压力显然是不同的。如果我们的系统，在架构上，能够做到通过简单的增加机器，就能提高系统的服务能力，那我们就可以说这种架构的伸缩性很强。那我们来想想传统架构和CQRS架构在性能和伸缩性上面的表现。
说到性能，大家一般会先思考一个系统的性能瓶颈在哪里。只要我们解决了性能瓶颈，那系统就意味着具有通过水平扩展来达到可伸缩的目的了（当然这里没有考虑数据存储的水平扩展）。所以，我们只要分析一下传统架构和CQRS架构的瓶颈点在哪里即可。
传统架构，瓶颈通常在底层数据库。然后我们一般的做法是，对于读：通常使用缓存就可以解决大部分查询问题；对于写：办法也有很多，比如分库分表，或者使用NoSQL，等等。比如阿里大量采用分库分表的方案，而且未来应该会全部使用高大上的OceanBase来替代分库分表的方案。通过分库分表，本来一台数据库服务器高峰时可能要承受10W的高并发写，如果我们把数据放到十台数据库服务器上，那每台机器只需要承担1W的写，相对于要承受10W的写，现在写1W就显得轻松很多了。所以，应该说数据存储对传统架构来说，也早已不再是瓶颈了。
传统架构一次数据修改的步骤是：1）从DB取出数据到内存；2）内存修改数据；3）更新数据回DB。总共涉及到2次数据库IO。
然后CQRS架构，CQ两端加起来所用的时间肯定比传统架构要多，因为CQRS架构最多有3次数据库IO，1）持久化命令；2）持久化事件；3）根据事件更新读库。为什么说最多？因为持久化命令这一步不是必须的，有一种场景是不需要持久化命令的。CQRS架构中持久化命令的目的是为了做幂等处理，即我们要防止同一个命令被处理两次。那哪一种场景下可以不需要持久化命令呢？就是当命令时在创建聚合根时，可以不需要持久化命令，因为创建聚合根所产生的事件的版本号总是为1，所以我们在持久化事件时根据事件版本号就能检测到这种重复。
所以，我们说，你要用CQRS架构，就必须要接受CQ数据的最终一致性，因为如果你以读库的更新完成为操作处理完成的话，那一次业务场景所用的时间很可能比传统架构要多。但是，如果我们以C端的处理为结束的话，则CQRS架构可能要快，因为C端可能只需要一次数据库IO。我觉得这里有一点很重要，对于CQRS架构，我们更加关注C端处理完成所用的时间；而Q端的处理稍微慢一点没关系，因为Q端只是供我们查看数据用的（最终一致性）。我们选择CQRS架构，就必须要接受Q端数据更新有一点点延迟的缺点，否则就不应该使用这种架构。所以，希望大家在根据你的业务场景做架构选型时一定要充分认识到这一点。
另外，上面再谈到数据一致性时提到，传统架构会使用事务来保证数据的强一致性；如果事务越复杂，那一次事务锁的表就越多，锁是系统伸缩性的大敌；而CQRS架构，一个命令只会修改一个聚合根，如果要修改多个聚合根，则通过Saga来实现。从而绕过了复杂事务的问题，通过最终一致性的思路做到了最大的并行和最少的并发，从而整体上提高系统的吞吐能力。
所以，总体来说，性能瓶颈方面，两种架构都能克服。而只要克服了性能瓶颈，那伸缩性就不是问题了（当然，这里我没有考虑数据丢失而带来的系统不可用的问题。这个问题是所有架构都无法回避的问题，唯一的解决办法就是数据冗余，这里不做展开了）。两者的瓶颈都在数据的持久化上，但是传统的架构因为大部分系统都是要存储数据到关系型数据库，所以只能自己采用分库分表的方案。而CQRS架构，如果我们只关注C端的瓶颈，由于C端要保存的东西很简单，就是命令和事件；如果你信的过一些成熟的NoSQL（我觉得使用文档性数据库如MongoDB这种比较适合存储命令和事件），且你也有足够的能力和经验去运维它们，那可以考虑使用NoSQL来持久化。如果你觉得NoSQL靠不住或者没办法完全掌控，那可以使用关系型数据库。但这样你也要付出努力，比如需要自己负责分库分表来保存命令和事件，因为命令和事件的数据量都是很大的。不过目前一些云服务如阿里云，已经提供了DRDS这种直接支持分库分表的数据库存储方案，极大的简化了我们存储命令和事件的成本。就我个人而言，我觉得我还是会采用分库分表的方案，原因很简单：确保数据可靠落地、成熟、可控，而且支持这种只读数据的落地，框架内置要支持分库分表也不是什么难事。所以，通过这个对比我们知道传统架构，我们必须使用分库分表（除非阿里这种高大上可以使用OceanBase）；而CQRS架构，可以带给我们更多选择空间。因为持久化命令和事件是很简单的，它们都是不可修改的只读数据，且对kv存储友好，也可以选择文档型NoSQL，C端永远是新增数据，而没有修改或删除数据。最后，就是关于Q端的瓶颈，如果你Q端也是使用关系型数据库，那和传统架构一样，该怎么优化就怎么优化。而CQRS架构允许你使用其他的架构来实现Q，所以优化手段相对更多。
结束语
我觉得不论是传统架构还是CQRS架构，都是不错的架构。传统架构门槛低，懂的人也多，且因为大部分项目都没有什么大的并发写入量和数据量。所以应该说大部分项目，采用传统架构就OK了。但是通过本文的分析，大家也知道了，传统架构确实也有一些缺点，比如在扩展性、可用性、性能瓶颈的解决方案上，都比CQRS架构要弱一点。大家有其他意见，欢迎拍砖，交流才能进步，呵呵。所以，如果你的应用场景是高并发写、高并发读、大数据，且希望在扩展性、可用性、性能、可伸缩性上表现更优秀，我觉得可以尝试CQRS架构。但是还有一个问题，CQRS架构的门槛很高，我认为如果没有成熟的框架支持，很难使用。而目前据我了解，业界还没有很多成熟的CQRS框架，java平台有axon framework, jdon framework；.NET平台，ENode框架正在朝这个方向努力。所以，我想这也是为什么目前几乎没有使用CQRS架构的成熟案例的原因之一。另一个原因是使用CQRS架构，需要开发者对DDD有一定的了解，否则也很难实践，而DDD本身要理解没个几年也很难运用到实际。还有一个原因，CQRS架构的核心是非常依赖于高性能的分布式消息中间件，所以要选型一个高性能的分布式消息中间件也是一个门槛（java平台有RocketMQ），.NET平台我个人专门开发了一个分布式消息队列EQueue，呵呵。另外，如果没有成熟的CQRS框架的支持，那编码复杂度也会很复杂，比如Event Sourcing，消息重试，消息幂等处理，事件的顺序处理，并发控制，这些问题都不是那么容易搞定的。而如果有框架支持，由框架来帮我们搞定这些纯技术问题，开发人员只需要关注如何建模，实现领域模型，如何更新读库，如何实现查询，那使用CQRS架构才有可能，因为这样才可能比传统的架构开发更简单，且能获得很多CQRS架构所带来的好处。
这是一个使用Spring Boot和Axon以及Docker构建的Event Sorucing源码项目，技术特点：
1.使用Java 和Spring Boot实现微服务;
2.使用命令和查询职责分离 (CQRS) 和 Event Sourcing (ES) 的框架Axon Framework v2, MongoDB 和 RabbitMQ;
3.使用Docker构建 交付和运行;
4.集中配置和使用Spring Cloud服务注册;
5.使用Swagger 和 SpringFox 提供API文档
项目源码：
GitHub工作原理：
这个应用使用CQRS架构模式构建，在CQRS命令如ADD是和查询VIEW(where id=1)分离的，在这个案例中领域部分代码已经分离成两个组件：一个是属于命令这边的微服务和属性查询这边的微服务。
微服务是单个职责的功能，自己的数据存储，每个能彼此独立扩展部署。
属于命令这边的微服务和属性查询这边的微服务都是使用Spring Boot框架开发的，在命令微服务和查询微服务之间通讯是事件驱动，事件是通过RabbitMQ消息在微服务组件之间传递，消息提供了一种进程节点或微服务之间可扩展的事件载体，包括与传统遗留系统或其他系统的松耦合通讯都可以通过消息进行。
请注意，服务之间不能彼此共享数据库，这是很重要，因为微服务应该是高度自治自主的，这样反过来有助于服务能够彼此独立地扩展伸缩规模。
CQRS中命令是“改变状态的动作”。命令的微服务包含所有领域逻辑和业务规则，命令被用于增加新的产品或改变它们的状态，这些命令针对某个具体产品的执行会导致事件Event产生，这会通过Axon框架持久化到MongoDB中，然后通过RabbitMQ传播给其他节点进程或微服务。
在event-sourcing中，事件是状态改变的原始记录，它们用于系统来重新建立实体的当前状态（通过重新播放过去的事件到当前就可以构建当前的状态），这听上去会很慢，但是实际上，事件都很简单，执行非常快，也能采取‘快照’策略进行优化。
请注意，在DDD中，实体是指一个聚合根实体。
上面是命令这边的微服务，下面看看查询这边的微服务：
查询微服务一般扮演一种事件监听器和视图角色，它监听到命令那边发出的事件，然后处理它们以符合查询这边的要求。
在这个案例中，查询这边只是简单建立和维持了一个 ‘materialised view’或‘projection’ ，其中保留了产品的最新状态，也就是产品id和描述以及是否被卖出等等信息，查询这边能够被复制多次以方便扩展，消息可以保留在RabbitMQ队列中实现持久保存，这种临时保存消息方式可以防止查询这边微服务当机。
命令微服务和查询微服务两者都有REST API，提供外界客户端访问。
下面看看如何通过Docker运行这个案例，需要 Ubuntu 16.04：
1.Docker ( v1.8.2)
2.Docker-compose ( v1.7.1)
在一个空目录，执行下面命令下载docker-compose:
$ wget https://raw.githubusercontent.com/benwilcock/microservice-sampler/master/docker-compose.yml
注意：不要更改文件名称。
启动微服务：只是简单一个命令：
$ docker-compose up
你会看到许多下载信息和日志输出在屏幕上，这是Docker image将被下载和运行。一共有六个docker，分别是： ‘mongodb’, ‘rabbitmq’, ‘config’, ‘discovery’, ‘product-cmd-side’, 和 ‘product-qry-side’.
使用下面命令进行测试增加一个新产品：
$ curl -X POST -v --header "Content-Type: application/json" --header "Accept: */*" "http://localhost:9000/products/add/1?name=Everything%20Is%20Awesome"
查询这个新产品：
$ curl http://localhost:9001/products/1
Microservices With Spring Boot, Axon CQRS/ES, and Docker
摘要: Docker 是 2014 年最为火爆的技术之一，几乎所有的程序员都听说过它。Docker 是一种“轻量级”容器技术，它几乎动摇了传统虚拟化技术的地位，现在国内外已经有越来越多的公司开始逐步使用 Docker 来替换现有的虚拟化平台了。作为一名 Java 程序员，我们是时候一起把 Docker 学起来了！本文会对虚拟化技术与 Docker 容器技术做一个对比，然后引出一些 ...
阅读全文
Spring Cloud Security OAuth2 是 Spring 对 OAuth2 的开源实现，优点是能与Spring Cloud技术线无缝集成，如果全部使用默认配置，开发者只需要添加注解就能完成 OAuth2 授权服务的搭建。
1. 添加依赖
授权服务是基于Spring Security的，因此需要在项目中引入两个依赖：
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-security</artifactId>
</dependency>
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-oauth2</artifactId>
</dependency>
前者为 Security，后者为Security的OAuth2扩展。
2. 添加注解和配置
在启动类中添加@EnableAuthorizationServer注解：
@SpringBootApplication
@EnableAuthorizationServer
public class AlanOAuthApplication {
public static void main(String[] args) {
SpringApplication.run(AlanOAuthApplication.class, args);
}
}
完成这些我们的授权服务最基本的骨架就已经搭建完成了。但是要想跑通整个流程，我们必须分配 client_id, client_secret才行。Spring Security OAuth2的配置方法是编写@Configuration类继承AuthorizationServerConfigurerAdapter，然后重写void configure(ClientDetailsServiceConfigurer clients)方法，如：
@Override
public void configure(ClientDetailsServiceConfigurer clients) throws Exception {
clients.inMemory() // 使用in-memory存储
.withClient("client") // client_id
.secret("secret") // client_secret
.authorizedGrantTypes("authorization_code") // 该client允许的授权类型
.scopes("app"); // 允许的授权范围
}
3. 授权流程
访问授权页面：
localhost:8080/oauth/authorize?client_id=client&response_type=code&redirect_uri=http://www.baidu.com
此时浏览器会让你输入用户名密码，这是因为 Spring Security 在默认情况下会对所有URL添加Basic Auth认证。默认的用户名为user, 密码是随机生成的，在控制台日志中可以看到。
画风虽然很简陋，但是基本功能都具备了。点击Authorize后，浏览器就会重定向到百度，并带上code参数：
拿到code以后，就可以调用
POST/GET http://client:secret@localhost:8080/oauth/token
来换取access_token了：
curl -X POST -H "Cache-Control: no-cache" -H "Content-Type: application/x-www-form-urlencoded" -d 'grant_type=authorization_code&code=Li4NZo&redirect_uri=http://www.baidu.com' "http://client:secret@localhost:8080/oauth/token"
返回如下：
{
"access_token": "32a1ca28-bc7a-4147-88a1-c95abcc30556",
"token_type": "bearer",
"expires_in": 2591999,
"scope": "app"
}
到此我们最最基本的授权服务就搭建完成了。然而，这仅仅是个demo，如果要在生产环境中使用，还需要做更多的工作。
4. 使用MySQL存储access_token和client信息
把授权服务器中的数据存储到数据库中并不难，因为 Spring Cloud Security OAuth 已经为我们设计好了一套Schema和对应的DAO对象。但在使用之前，我们需要先对相关的类有一定的了解。
4.1 相关接口
Spring Cloud Security OAuth2通过DefaultTokenServices类来完成token生成、过期等 OAuth2 标准规定的业务逻辑，而DefaultTokenServices又是通过TokenStore接口完成对生成数据的持久化。在上面的demo中，TokenStore的默认实现为InMemoryTokenStore，即内存存储。 对于Client信息，ClientDetailsService接口负责从存储仓库中读取数据，在上面的demo中默认使用的也是InMemoryClientDetialsService实现类。说到这里就能看出，要想使用数据库存储，只需要提供这些接口的实现类即可。庆幸的是，框架已经为我们写好JDBC实现了，即JdbcTokenStore和JdbcClientDetailsService。
4.2 建表
要想使用这些JDBC实现，首先要建表。框架为我们提前设计好了schema, 在github上：https://github.com/spring-projects/spring-security-oauth/blob/master/spring-security-oauth2/src/test/resources/schema.sql
在使用这套表结构之前要注意的是，对于MySQL来说，默认建表语句中主键是varchar(255)类型，在mysql中执行会报错，原因是mysql对varchar主键长度有限制。所以这里改成128即可。其次，语句中会有某些字段为LONGVARBINARY类型，它对应mysql的blob类型，也需要修改一下。
4.3 配置
数据库建好后，下一步就是配置框架使用JDBC实现。方法还是编写@Configuration类继承AuthorizationServerConfigurerAdapter：
@Autowired
private AuthenticationManager authenticationManager;
@Autowired
private DataSource dataSource;
@Bean // 声明TokenStore实现
public TokenStore tokenStore() {
return new JdbcTokenStore(dataSource);
}
@Bean // 声明 ClientDetails实现
public ClientDetailsService clientDetails() {
return new JdbcClientDetailsService(dataSource);
}
@Override // 配置框架应用上述实现
public void configure(AuthorizationServerEndpointsConfigurer endpoints) throws Exception {
endpoints.authenticationManager(authenticationManager);
endpoints.tokenStore(tokenStore());
// 配置TokenServices参数
DefaultTokenServices tokenServices = new DefaultTokenServices();
tokenServices.setTokenStore(endpoints.getTokenStore());
tokenServices.setSupportRefreshToken(false);
tokenServices.setClientDetailsService(endpoints.getClientDetailsService());
tokenServices.setTokenEnhancer(endpoints.getTokenEnhancer());
tokenServices.setAccessTokenValiditySeconds( (int) TimeUnit.DAYS.toSeconds(30)); // 30天
endpoints.tokenServices(tokenServices);
}
完成这些后，框架就会将中间产生的数据写到mysql中了。oauth_client_details是client表，可以直接在该表中添加记录来添加client:
4.4 需要注意的地方
这里不得不说 Spring 设计有一个奇葩地的方。注意看oauth_access_token表是存放访问令牌的，但是并没有直接在字段中存放token。Spring 使用OAuth2AccessToken来抽象与令牌有关的所有属性，在写入到数据库时，Spring将该对象通过JDK自带的序列化机制序列成字节直接保存到了该表的token字段中。也就是说，如果只看数据表你是看不出access_token的值是多少，过期时间等信息的。这就给资源服务器的实现带来了麻烦。我们的资源提供方并没有使用Spring Security，也不想引入 Spring Security 的任何依赖，这时候就只能将 DefaultOAuth2AccessToken的源码copy到资源提供方的项目中，然后读取token字段并反序列化还原对象来获取token信息。但是如果这样做还会遇到反序列化兼容性的问题，具体解决方法参考我另一篇博文:http://blog.csdn.net/neosmith/article/details/52539614
5. 总结
至此一个能在生产环境下使用的授权服务就搭建好了。其实我们在实际使用时应该适当定制JdbcTokenStore或ClientDetailsService来实适应业务需要，甚至可以直接从0开始实现接口，完全不用框架提供的实现。另外，Spring 直接将DefaultOAuth2AccessToken序列化成字节保存到数据库中的设计，我认为是非常不合理的。或许设计者的初衷是保密access_token，但是通过加密的方法也可以实现，完全不应该直接扔字节。不过通过定制TokenStore接口，我们可以使用自己的表结构而不拘泥于默认实现。
http://blog.csdn.net/tracker_w/article/category/6360121
http://blog.csdn.net/neosmith/article/details/52539927
在Spring Cloud Netflix栈中，各个微服务都是以HTTP接口的形式暴露自身服务的，因此在调用远程服务时就必须使用HTTP客户端。我们可以使用JDK原生的URLConnection、Apache的Http Client、Netty的异步HTTP Client, Spring的RestTemplate。但是，用起来最方便、最优雅的还是要属Feign了。
Feign简介
Feign是一种声明式、模板化的HTTP客户端。在Spring Cloud中使用Feign, 我们可以做到使用HTTP请求远程服务时能与调用本地方法一样的编码体验，开发者完全感知不到这是远程方法，更感知不到这是个HTTP请求。比如：
@Autowired
private AdvertGropRemoteService service; // 远程服务
public AdvertGroupVO foo(Integer groupId) {
return service.findByGroupId(groupId); // 通过HTTP调用远程服务
}
开发者通过service.findByGroupId()就能完成发送HTTP请求和解码HTTP返回结果并封装成对象的过程。
Feign的定义
为了让Feign知道在调用方法时应该向哪个地址发请求以及请求需要带哪些参数，我们需要定义一个接口：
@FeignClient(name = "ea") // [A]
public interface AdvertGroupRemoteService {
@RequestMapping(value = "/group/{groupId}", method = RequestMethod.GET) // [B]
AdvertGroupVO findByGroupId(@PathVariable("groupId") Integer adGroupId) // [C]
@RequestMapping(value = "/group/{groupId}", method = RequestMethod.PUT)
void update(@PathVariable("groupId") Integer groupId, @RequestParam("groupName") String groupName)
A: @FeignClient用于通知Feign组件对该接口进行代理(不需要编写接口实现)，使用者可直接通过@Autowired注入。
B: @RequestMapping表示在调用该方法时需要向/group/{groupId}发送GET请求。
C: @PathVariable与SpringMVC中对应注解含义相同。
Spring Cloud应用在启动时，Feign会扫描标有@FeignClient注解的接口，生成代理，并注册到Spring容器中。生成代理时Feign会为每个接口方法创建一个RequetTemplate对象，该对象封装了HTTP请求需要的全部信息，请求参数名、请求方法等信息都是在这个过程中确定的，Feign的模板化就体现在这里。
在本例中，我们将Feign与Eureka和Ribbon组合使用，@FeignClient(name = "ea")意为通知Feign在调用该接口方法时要向Eureka中查询名为ea的服务，从而得到服务URL。
Feign的Encoder、Decoder和ErrorDecoder
Feign将方法签名中方法参数对象序列化为请求参数放到HTTP请求中的过程，是由编码器(Encoder)完成的。同理，将HTTP响应数据反序列化为java对象是由解码器(Decoder)完成的。
默认情况下，Feign会将标有@RequestParam注解的参数转换成字符串添加到URL中，将没有注解的参数通过Jackson转换成json放到请求体中。注意，如果在@RequetMapping中的method将请求方式指定为POST，那么所有未标注解的参数将会被忽略，例如：
@FeignClient(name = "ea") // [A]
public interface AdvertGroupRemoteService {
@RequestMapping(value = "/group/{groupId}", method = RequestMethod.GET) // [B]
AdvertGroupVO findByGroupId(@PathVariable("groupId") Integer adGroupId) // [C]
@RequestMapping(value = "/group/{groupId}", method = RequestMethod.PUT)
void update(@PathVariable("groupId") Integer groupId, @RequestParam("groupName") String groupName)
此时因为声明的是GET请求没有请求体，所以obj参数就会被忽略。
在Spring Cloud环境下，Feign的Encoder*只会用来编码没有添加注解的参数*。如果你自定义了Encoder, 那么只有在编码obj参数时才会调用你的Encoder。对于Decoder, 默认会委托给SpringMVC中的MappingJackson2HttpMessageConverter类进行解码。只有当状态码不在200 ~ 300之间时ErrorDecoder才会被调用。ErrorDecoder的作用是可以根据HTTP响应信息返回一个异常，该异常可以在调用Feign接口的地方被捕获到。我们目前就通过ErrorDecoder来使Feign接口抛出业务异常以供调用者处理。
Feign的HTTP Client
Feign在默认情况下使用的是JDK原生的URLConnection发送HTTP请求，没有连接池，但是对每个地址会保持一个长连接，即利用HTTP的persistence connection 。我们可以用Apache的HTTP Client替换Feign原始的http client, 从而获取连接池、超时时间等与性能息息相关的控制能力。Spring Cloud从Brixtion.SR5版本开始支持这种替换，首先在项目中声明Apache HTTP Client和feign-httpclient依赖：
@RequestMapping(value = "/group/{groupId}", method = RequestMethod.GET)
void update(@PathVariable("groupId") Integer groupId, @RequestParam("groupName") String groupName, DataObject obj);
然后在application.properties中添加：
feign.httpclient.enabled=true
总结
通过Feign， 我们能把HTTP远程调用对开发者完全透明，得到与调用本地方法一致的编码体验。这一点与阿里Dubbo中暴露远程服务的方式类似，区别在于Dubbo是基于私有二进制协议，而Feign本质上还是个HTTP客户端。如果是在用Spring Cloud Netflix搭建微服务，那么Feign无疑是最佳选择。
http://blog.csdn.net/tracker_w/article/category/6360121
http://blog.csdn.net/neosmith/article/details/52449921
2016
基于SPRING CLOUD的微服务框架
http://jhipster.cn/
摘要Spring 框架给企业软件开发者提供了常见问题的通用解决方案，包括那些在未来开发中没有意识到的问题。但是，它构建的 J2EE 项目变得越来越臃肿，逐渐被 Spring Boot 所替代。Spring Boot 让我们创建和运行项目变得更为迅速，现在已经有越来越多的人使用它。我们已经在几个项目中使用了 Spring Boot ，今天我们就来一起讨论一下如何改进 Spring Boot 应用的性能。
Spring 框架给企业软件开发者提供了常见问题的通用解决方案，包括那些在未来开发中没有意识到的问题。但是，它构建的 J2EE 项目变得越来越臃肿，逐渐被 Spring Boot 所替代。Spring Boot 让我们创建和运行项目变得更为迅速，现在已经有越来越多的人使用它。我们已经在几个项目中使用了 Spring Boot ，今天我们就来一起讨论一下如何改进 Spring Boot 应用的性能。
首先，从之前我在开发中遇到的一个问题说起。在一次查看项目运行日志的时候，我偶然发现了一个问题，日志里显示这个项目总是加载 Velocity 模板引擎，但实际上这个项目是一个没有 web 页面的 REST Service 项目。于是我花了一点时间去寻找产生这个问题的原因，以及如何改进 Spring Boot 应用的性能。在查找了相关的资料后，我得出的结论如下：
组件自动扫描带来的问题
默认情况下，我们会使用 @SpringBootApplication 注解来自动获取的应用的配置信息，但这样也会给应用带来一些副作用。使用这个注解后，会触发自动配置（ auto-configuration ）和 组件扫描 （ component scanning），这跟使用 @Configuration、@EnableAutoConfiguration 和 @ComponentScan 三个注解的作用是一样的。这样做给开发带来方便的同时，也会有两方面的影响：
1、会导致项目启动时间变长。当启动一个大的应用程序,或将做大量的集成测试启动应用程序时，影响会特别明显。
2、会加载一些不需要的多余的实例（beans）。
3、会增加 CPU 消耗。
针对以上两个情况，我们可以移除 @SpringBootApplication 和 @ComponentScan 两个注解来禁用组件自动扫描，然后在我们需要的 bean 上进行显式配置：
// 移除 @SpringBootApplication and @ComponentScan, 用 @EnableAutoConfiguration 来替代
@Configuration
@EnableAutoConfiguration
public class SampleWebUiApplication {
// 
// 用 @Bean 注解明确显式配置，以便被 Spring 扫描到
@Bean
public MessageController messageController(MessageRepository messageRepository) {
return new MessageController(messageRepository);
} 如何避免组件自动扫描带来的问题
我们在上面提到，@SpringBootApplication 注解的作用跟 @EnableAutoConfiguration 注解的作用是相当的，那就意味着它也能带来上述的三个问题。要避免这些问题，我们就要知道我们需要的组件列表是哪些，可以用 -Ddebug 的方式来帮助我们明确地定位：
mvn spring-boot:run -Ddebug … ========================= AUTO-CONFIGURATION REPORT ========================= Positive matches: ----------------- DispatcherServletAutoConfiguration - @ConditionalOnClass classes found: org.springframework.web.servlet.DispatcherServlet (OnClassCondition) - found web application StandardServletEnvironment (OnWebApplicationCondition) ...
接着拷贝 Positive matches 中列出的信息：
DispatcherServletAutoConfiguration
EmbeddedServletContainerAutoConfiguration
ErrorMvcAutoConfiguration
HttpEncodingAutoConfiguration
HttpMessageConvertersAutoConfiguration
JacksonAutoConfiguration
JmxAutoConfiguration
MultipartAutoConfiguration
ServerPropertiesAutoConfiguration
PropertyPlaceholderAutoConfiguration
ThymeleafAutoConfiguration
WebMvcAutoConfiguration
WebSocketAutoConfiguration
然后来更新项目配置，显式地引入这些组件，引入之后，再运行一下应用确保没有错误发生：
@Configuration
@Import({
DispatcherServletAutoConfiguration.class,
EmbeddedServletContainerAutoConfiguration.class,
ErrorMvcAutoConfiguration.class,
HttpEncodingAutoConfiguration.class,
HttpMessageConvertersAutoConfiguration.class,
JacksonAutoConfiguration.class,
JmxAutoConfiguration.class,
MultipartAutoConfiguration.class,
ServerPropertiesAutoConfiguration.class,
PropertyPlaceholderAutoConfiguration.class,
ThymeleafAutoConfiguration.class,
WebMvcAutoConfiguration.class,
WebSocketAutoConfiguration.class,
})
public class SampleWebUiApplication {}
在上面的代码中，我们可以删掉我们不需要的组件信息，来提高应用的性能，比如在我的项目中，不需要 JMX 和 WebSocket 功能，我就删掉了它们。删掉之后，再次运行项目，确保一切正常。
将Servlet容器变成Undertow
默认情况下，Spring Boot 使用 Tomcat 来作为内嵌的 Servlet 容器。我们可以启动项目，然后用 VisualVM 或者 JConsole 来查看应用所占的内存情况：
以上是我使用 Spring Boot 的默认方式启动应用后，用 VisualVM 监控到的内存的占用情况：堆内存占用 110M，16 个线程被开启。
可以将 Web 服务器切换到 Undertow 来提高应用性能。Undertow 是一个采用 Java 开发的灵活的高性能 Web 服务器，提供包括阻塞和基于 NIO 的非堵塞机制。Undertow 是红帽公司的开源产品，是 Wildfly 默认的 Web 服务器。首先，从依赖信息里移除 Tomcat 配置：
<exclusions>
<exclusion>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-tomcat</artifactId>
</exclusion>
</exclusions>
然后添加 Undertow：
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-undertow</artifactId>
</dependency>
启动项目后，用 VisualVM 监控到的信息显示：堆内存占用 90M，13个线程被开启。
总结
这些都是我们在项目开发中使用到的一些优化 Spring Boot 应用的小技巧，对于大的应用性能的提高还是很明显的。大家可以尝试一下，然后告诉我们你的测试结果。
最后，附上代码，大家可以去这里下载：spring-boot-performance。
文中大部分内容参考英国一个架构师的博客 和 DZone 近期发布的文章，在此感谢两位大牛。参考文章及链接：
（1）Spring Boot 性能优化：Spring Boot Performance；
（2）Spring Boot 内存优化：Spring Boot Memory Performance。
（3）https://www.techempower.com/benchmarks/；
（4）Spring 应用程序优化：Optimizing Spring Framework for App Engine Applications。