#微服务

架构运维
开篇： 如果在诸多热门云计算技术中，诸如容器、微服务、DevOps、OpenStack 等，找出一个最火的方向，那么非微服务莫属。尽管话题炙手可热，但对传统行业来说，微服务落地和方法论目前处于起步阶段。 本报告于2017年11月份展开，从驱动因素、落地现状、和容器关系、架构体系、未来趋势和落地方法论等方面对微服务进行了分析。希望能够为传统企业微服务决策、规划和实施提供依据和解决办法。 驱动因素传统行业对IT效率的变革需求是微服务成长土壤,业务模式创新重塑导致系统更新频繁、应用复杂度急剧升高，传统架构不堪重负。 微服务架构具有明显的好处，尤其是在应对复杂业务系统的多变需求方面。在本次调研企业中，每个月都要进行业务系统更新的比例占63%，只有不到20%的企业半年以上更新一次系统。 加快互联网+步伐成为许多传统企业的必然选择。业务场景、用户习惯和行为在迅速变化，许多传统行业线上业务出...

Spring Cloud
2016年，我在博客中发表过一篇《微服务架构的基础框架选择：Spring Cloud还是Dubbo？》获得了很大的阅读量和转载量。在这篇文章中，我主要对比了Spring Cloud与Dubbo所具备的能力，并阐述了个人推崇Spring Cloud的原因。但是，最近各大技术社区出现了不少类似的文章，观点比较激进，对于Spring Cloud的褒扬远胜于Dubbo，但是这些评价很多都忽略了Spring Cloud与Dubbo在设计视角上的不同。其实在前文中我也说明了Dubbo与Spring Cloud的对比本身就不公平，因为两者产出的目标格局是不一样的。所以，就目前阶段来说，大家对于框架的选择上，还是要综合考虑自身团队与遗留业务系统的特点来确定更合适的技术栈，而不是盲从于“时髦”的架构体系。 昨天看到了开源中国对Dubbo社区维护者的访谈，内容非常不错。所以这里分享给大家。其实，在最近...

架构运维
如果在诸多热门云计算技术中，诸如容器、微服务、DevOps等，找出一个最火的方向，那么非微服务莫属。在小数推荐的这篇文章里，做与不做微服务好像理由都很充分。另外，诞生几十年的康威定律，在组织结构调整和变革方面，依然神采奕奕。 创建一种新的软件项目架构，来封装离散服务，对于全新的项目来说，这是非常简单的。但是，对于大多数软件开发者来说，谁又有大把的奢侈时间一直用在全新项目上呢？ 大多数软件开发人员职责更多是维护或增加现有软件系统的功能。但是，如果问开发人员究竟是愿意构建全新的项目，还是维护一个现有的系统，那么支持新项目的呼声肯定会成为压倒性的声音。事实上，希望与新技术或新项目合作也是开发人员离职的原因之一。为什么呢？ 1. 识别问题容易，但修复很难维护现有系统时，很容易识别架构的问题。为什么？因为基于良好的架构，系统很容易调整。 当需要去调整一个没有设计封装波动的已有系统时，架构的...

Spring Cloud
在微服务架构下，你的服务可能由不同的团队提供和维护，在这种情况下，接口的开发和维护可能会带来一些问题，比如服务端调整架构或接口调整而对消费者不透明，导致接口调用失败。 为解决这些问题，Ian Robinson提出了一个以服务消费者定义契约为驱动的开发模式：“Consumer-Driver Contracts(CDC)”，就是：消费者驱动契约。 通常我们开发中主要由服务提供方约定接口，虽然提供方架构调整或改变接口之前通常会通知消费者，但可能还存在上述风险，如果上线出现问题就GG了，而CDC则是以消费者提出接口契约，交由服务提供方实现，并以测试用例对契约进行产生约束，所以服务提供方在满足测试用例的情况下可以自行更改接口或架构实现而不影响消费者。 消费者驱动的契约测试（Consumer-Driven Contracts，简称CDC），是指从消费者业务实现的角度出发，驱动出契约，再基于契约...

架构运维
虽然之前在《Spring Cloud构建微服务架构》系列文章中介绍了Hystrix服务降级与Hystrix断路器的概念。但是，还是一直收到这样的提问：降级与熔断区别是什么？并且在很多交流过程中，发现有不少童鞋对降级和熔断的概念有混淆的情况。所以，这篇博文准备换一种方式来说说这两个概念，以帮助读者更好的理解之前两篇文章中介绍的这两个重要知识。 下面通过一个日常的故事来说明一下什么是服务降级，什么是熔断。 故事的背景是这样的：由于小强在工作中碰到一些问题，于是想请教一下业界大牛小壮。于是发生了下面的两个场景： 小强在拿起常用手机拨号时发现该手机没有能够拨通，所以就拿出了备用手机拨通了某A的电话，这个过程就叫做降级（主逻辑失败采用备用逻辑的过程）。 由于每次小壮的解释都属于长篇大论，不太容易理解，所以小强每次找小壮沟通的时候都希望通过常用手机来完成，因为该手机有录音功能，这样自己可以慢慢消...

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

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

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

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

架构运维
DDD社区官网上一篇关于聚合设计的几个原则的简单讨论：文章地址：http://dddcommunity.org/library/vernon_2011/，该地址中包含了一篇关于介绍如何有效的设计聚合的一些原则，共3个pdf文件。该文章中指出了以下几个聚合设计的原则： 聚合是用来封装真正的不变性，而不是简单的将对象组合在一起； 聚合应尽量设计的小； 聚合之间的关联通过ID，而不是对象引用； 聚合内强一致性，聚合之间最终一致性； 上面这几条原则，作者通过一个例子来逐步阐述。下面我按照我的理解对每个原则做一个简单的描述。 聚合是用来封装真正的不变性，而不是简单的将对象组合在一起这个原则，就是强调聚合的真正用途除了封装我们本身所关心的信息外，最主要的目的是为了封装业务规则，保证数据的一致性。在我看来，这一点是设计聚合时最重要和最需要考虑的点；当我们在设计聚合时，要多想想当前聚合封装了哪些...

架构运维
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中实现了。你也是知道的，不同的团队使用不同的方式来实现了不同的微服务。 如果你不去做一些中心化和抽象化的事情，你将会死于不同的认证方式以及不同的速率限制实...