#架构设计

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

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

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

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

架构运维
本系列内容是来自Mashape.com的Marco在nginx.conf上的一次演讲。 上一集我们介绍了为什么我们需要API网关：微服务与API 网关（上）: 为什么需要API网关？ 本系列第一部分（上集）主要介绍了单体和微服务之间的差别，以及为什么我们需要一个API网关等等。 本系列的第二部分（也就是本集）主要关注Mashape.com的API网关，Kong，这个框架。我们来看看怎么使用这个框架。 ok，开始吧。 目录 23:52 API网关和Kong能为你做些什么（API Gateways and Kong Can Help） API 网关可以通过实现一些中间件来解决一些问题，这些中间件的功能你就不用再到每个service中实现了。你也是知道的，不同的团队使用不同的方式来实现了不同的微服务。 如果你不去做一些中心化和抽象化的事情，你将会死于不同的认证方式以及不同的速率限制实...

架构运维
本文是来自于Macro在一次大会上的一个分享。 本系列共有两个部分，主要关注我们如何以及为什么要在我们的微服务应用中部署API 网关。第二部分主要关注我们如何把Mashape的开源网关组件Kong运用到我们自己的微服务架构当中。* 目录 0:00 微服务与网关（Microservices & API Gateways） 大家好，我叫Macro，今天我们谈论有关微服务和网关的话题。我是Mashape的CTO,也同时是开源网关Kong的开发者之一。Kong是一个API网关，今天我们就来窥探一下它究竟是怎么工作的以及它如何运用到你的微服务架构中去。 0:23 主题（Topics） 为了明白我们为什么需要API网关，我将从单体架构vs微服务架构谈起。这两个有什么不同点呢？然后我会介绍API网关模式以及它是如何适应“面向微服务”的架构的。然后我们会讨论Kong以及NGINX。 ...

架构运维
原文： http://static.olivergierke.de/lectures/ddd-and-spring/ 介绍这篇文章是的介绍一下领域驱动设计的基础构件、概念和Java的web应用（主要是基于Spring框架）之间的关系和区别。这篇文章的第二部分讲了怎么把实体、聚合根、仓储映射到使用Spring框架的Java应用中。 领域驱动设计Eric Evans的《领域驱动设计》无疑是软件设计领域最重要的几本书之一。这本书主要集中在软件开发中如何处理领域和软件的映射关系— 开始强调领域通用语言(domain ubiquitous language)，通过语言来提取模型，最终映射到一个可工作的软件上。我们已经对软件设计模式比较熟悉了，他是用于描述和提炼Class和Class关系的技术语言。而DDD是一种用于程序员和业务沟通的更通用的语言，使用DDD可以最终将代码映射到模型上。 基础...

架构运维
我承认我是标题党， 为什么要写这篇充满争议的文章？目前架构师这个职位特别火热，程序员的目标都是成为一个令人尊敬的架构师。但是我们真的理解架构师应该做些什么？很多人把架构师和框架师等同起来，认为研究框架多的才是架构师下面说的情况请勿对号入座。 盲目的追新：技术人员的喜好往往是什么技术流行就追什么技术。现在的技术发展快，前后端不断涌现各种框架，我们恨不得把这些框架都用在自己的项目里才行，要不然怎么好意思和别人打招呼啊。我亲身经历，有个技术人员一定要把原来单元测试框架的xml初始数据改为json，他的原话是”json看的更舒服”，但是改完后，我们的单元测试反而难落地了，原因是原来的单元测试框架有个工具是可以将表中的数据自动生成xml的，而改成json后，我们必须手写json数据了。 他的喜好不包括给大家更好用的工具。 按技术站队，以结果反推：很多人把手段当成了目的，成为了框架的信徒。用了...

架构运维
接上篇，我们采用了领域驱动的开发方式，使用了充血模型，享受了他的好处，但是也不得不面对他带来的弊端。这个弊端在分布式的微服务架构下面又被放大。 事务一致性事务一致性的问题在Monolithic下面不是大问题，在微服务下面却是很致命，我们回顾一下所谓的ACID原则 Atomicity - 原子性，改变数据状态要么是一起完成，要么一起失败 Consistency - 一致性，数据的状态是完整一致的 Isolation - 隔离线，即使有并发事务，互相之间也不影响 Durability - 持久性， 一旦事务提交，不可撤销 在单体服务和关系型数据库的时候，我们很容易通过数据库的特性去完成ACID。但是一旦你按照DDD拆分聚合根-微服务架构，他们的数据库就已经分离开了，你就要独立面对分布式事务，要在自己的代码里面满足ACID。对于分布式事务，大家一般会想到以前的JTA标准，2PC两段式提...

架构运维
上篇我们聊了微服务的DDD之间的关系，很多人还是觉得很虚幻，DDD那么复杂的理论，聚合根、值对象、事件溯源，到底我们该怎么入手呢？实际上DDD和面向对象设计、设计模式等等理论有千丝万缕的联系，如果不熟悉OOA、OOD，DDD也是使用不好的。不过学习这些OO理论的时候，大家往往感觉到无用武之地，因为大部分的Java程序员开发生涯是从学习J2EE经典的分层理论开始的（Action、Service、Dao），在这种分层理论中，我们基本没有啥机会使用那些所谓的“行为型”的设计模式，这里的核心原因，就是J2EE经典分层的开发方式是“贫血模型”。 Martin Fowler在他的《企业应用架构模式》这本书中提出了两种开发方式“事务脚本”和“领域模型”，这两种开发分别对应了“贫血模型”和“充血模型”。 事务脚本开发模式 事务脚本的核心是过程，可以认为大部分的业务处理都是一条条的SQL，事务脚本把单...

架构运维
微服务架构和SOA区别微服务现在辣么火，业界流行的对比的却都是所谓的Monolithic单体应用，而大量的系统在十几年前都是已经是分布式系统了，那么微服务作为新的理念和原来的分布式系统，或者说SOA（面向服务架构）是什么区别呢？ 我们先看相同点： 需要Registry，实现动态的服务注册发现机制； 需要考虑分布式下面的事务一致性，CAP原则下，两段式提交不能保证性能，事务补偿机制需要考虑； 同步调用还是异步消息传递，如何保证消息可靠性？SOA由ESB来集成所有的消息； 都需要统一的Gateway来汇聚、编排接口，实现统一认证机制，对外提供APP使用的RESTful接口； 同样的要关注如何再分布式下定位系统问题，如何做日志跟踪，就像我们电信领域做了十几年的信令跟踪的功能； 那么差别在哪？ 是持续集成、持续部署？对于CI、CD（持续集成、持续部署），这本身和敏捷、DevOps是交织...

架构运维
原文是 Martin Flower 于 2014 年 3 月 25 日写的《Microservices》。 微服务“微服务架构（Microservice Architecture）”一词在过去几年里广泛的传播，它用于描述一种设计应用程序的特别方式，作为一套独立可部署的服务。目前，这种架构方式还没有准确的定义，但是在围绕业务能力的组织、自动部署（automated deployment）、端智能（intelligence in the endpoints）、语言和数据的分散控制，却有着某种共同的特征。 “微服务（Microservices）”——只不过在满大街充斥的软件架构中的一新名词而已。尽管我们非常鄙视这样的东西，但是这玩意所描述的软件风格，越来越引起我们的注意。在过去几年里，我们发现越来越多的项目开始使用这种风格，以至于我们身边的同事在构建企业级应用时，把它理所当然的认为这是...

架构运维
上集我们阐述了使用微服务体系架构的关键障碍是领域模型，事务和查询，这三个障碍似乎和功能拆分具有天然的对抗。只要功能拆分了，就涉及这三个难题。 然后我们向你展示了一种解决方案就是将每个服务的业务逻辑实现为一组DDD聚合。然后每个事务只能更新或创建一个单独的聚合。然后通过事件来维护聚合（和服务）之间的数据一致性。 在本集中，我们将会向你介绍使用事件的时候遇到了一个新的问题，就是怎么样通过原子方式更新聚合和发布事件。然后会展示如何使用事件源来解决这个问题，事件源是一种以事件为中心的业务逻辑设计和持久化的方法。之后，我们会阐述微服务架构下的查询困难的问题。然后向你介绍一种称为命令查询责任分离（CQRS）的方法来实现可扩展和高性能的查询。 可靠地更新状态和发布事件从表面上看，使用事件来保持聚合之间的一致性似乎很简单。 当一个服务创建或更新数据库的一个聚合时，它只是简单地发布一个事件。但是，这只...

架构运维
微服务架构变得越来越流行了。它是模块化的一种方法。它把一整块应用拆分成一个个服务。它让团队在开发大型复杂的应用时更快地交付出高质量的软件。团队成员们可以轻松地接受到新技术，因为他们可以使用最新且推荐的技术栈来实现各自的服务。微服务架构也通过让每个服务都被部署在最佳状态的硬件上而改善了应用的扩展性。 但微服务不是万能的。特别是在 领域模型、事务以及查询这几个地方，似乎总是不能适应拆分。或者说这几块也是微服务需要专门处理的地方，相对于过去的单体架构。 在这篇文章中，我会描述一种开发微服务的方法，这个方法可以解决这些问题。主要是通过领域模型设计，也就是DDD以及事件源（Event Sourcing）以及CQRS。让我们首先来看看开发人员在开发微服务的时候会遇到哪些问题吧。 微服务开发过程中的挑战模块化在开发大型复杂的应用的时候是非常有必要的。 现在许多应用大到一个人根本无法完成。而且复杂到...

Spring Cloud
最近一段时间不论互联网还是传统行业，凡是涉及信息技术范畴的圈子几乎都在讨论微服务架构。近期也看到各大技术社区开始组织一些沙龙和论坛来分享Spring Cloud的相关实施经验，这对于最近正在整理Spring Cloud相关套件内容与实例应用的我而言，还是有不少激励的。 目前，Spring Cloud在国内的知名度并不高，在前阵子的求职过程中，与一些互联网公司的架构师、技术VP或者CTO在交流时，有些甚至还不知道该项目的存在。可能这也与国内阿里巴巴开源服务治理框架Dubbo有一定的关系，除了Dubbo本身较为完善的中文文档之外，不少科技公司的架构师均出自阿里系，所以就目前情况看，短期国内还是Dubbo的天下。 那么第一次实施微服务架构时，我们应该选择哪个基础框架更好呢？ 以下内容均为作者个人观点，知识面有限，如有不对，纯属正常，不喜勿喷。 Round 1：背景 Dubbo，是阿里巴巴服...