千人千面的微服务

为什么说千人千面的微服务呢，这个大家和身边的人聊聊就知道了，一说大家都知道，再仔细一聊才知道大家说的不是一个微服务。我也看过很多文章，本文也可以说是这些文章的读后感o(￣︶￣)o，我比较推崇老马的这个描述。下面就来说说我理解的微服务。

微服务第一条原则就是不要使用微服务

就想老马说的分布式的第一条准则（不要使用分布式）一样，能不使用微服务就不要使用，老马也说过 you must be too tall to use microservices，微服务会带来很多复杂度，如果治理能力更不上很可能适得其反，最后成了一大堆各自为战的微服务，得不偿失呀。 ThoughtWorks 肖然的银行组织的敏捷落地一文中有详细的介绍。

如果你没听过康威定律和 DDD 就不要提微服务

康威定律

微服务既是一种技术架构风格，也是一种组织架构风格，康威曾经说过：

任何设计(广义上的)系统的组织，都会产生这样一个设计，即该设计的结构与该组织的沟通结构相一致。

DDD

下面来简单说下 DDD 也就是领域驱动设计，领域驱动设计是一整套方法、工具、实践的集合，强调从业务出发，设计出一个可以不断演进的架构。

小结

我用这篇文章的一句话作为本段的结尾，我再稍微改下:

企业决定实践微服务前，请先检查组织内部是否已经做好准备，相关人员是否对此有正确的理解，全靠开发者本能的狂奔，肯定不会走太远。

微服务架构的九大特性

特性一:“组件化”与“多服务”

最开始的时候都是单体应用，到了现在变化越来越快，单体应用响应变化的能力太弱了，所以需要拆分成多个服务，一个良好的应用服务是通过内聚的服务边界和服务协议方面的演进机制，来提高单个应用响应变化的能力。
还有就是我觉得微服务的“微”是相对单体应用来说的，不是说这个服务的大小。

特性二:围绕“业务功能”组织团队

这里还要在提一下康威定律，如果不改变组织架构而只是从技术角度去实施微服务，那么组织架构迟早会成为实施微服务的阻碍。

特性三:“做产品”而不是“做项目”

产品和项目的生命周期在 PMI 中有明确的定义，大多人对这两个生命周期的定义也基本这样。产品的生命周期是从产品最初的概念一直到最后产品下线为止，项目的生命周期从某种角度来讲是产品的子生命周期（这个准确的说是项目生命周期中的开发生命周期，这里就不详细说了），项目的生命周期一般以产品上线为止，但是产品的生命周期还包括产品上线后的运营和下线等等。
强调做产品而不是做项目，是要强调在产品的运营阶段很重要。

特性四:“智能端点”与“傻瓜管道”

智能和傻瓜都是相对企业服务总线（ESB）来说的。微服务最常用的两种协议是:带有资源 API 的 HTTP “请求-响应”协议，和轻量级的消息发送协议。

智能端点

一般来讲是带有资源 API 的 HTTP“请求-响应”协议。关于 REST 的介绍我觉得实现领域驱动设计中讲的比较好：

从我的经验来看，符合 REST 原则的系统将具有更好的松耦合性。通常来讲添加新资源并在已有的资源中创建到新资源的链接是非常简单的。要添加的新的格式同样如此。另外基于 REST 的系统要是非常容易理解的，因为此时系统被分为很多较小的资源块，每一个资源块都可以独立的测试和调试，并且每一个资源块都表示了一个可重用的入口点。HTTP 的设计本身以及 URI 成熟的重写与缓存机制使得 RESTful HTTP 成为一种不错的架构选择，该架构具有很好的松耦合性和可伸缩性。

傻瓜管道

傻瓜管道的意思是通过一个轻量级的消息总线来进行消息发送。此时所选择的基础设施，通常是“傻瓜”(dumb)型的(仅仅像消息路由器所做的事情那样傻瓜)像 RabbitMQ 或 ZeroMQ 那样的简单实现，即除了提供可靠的异步机制 (fabric) 以外不做其他任何事情，智能功能存在于那些生产和消费诸多消息的各个端点中，即存在于各个服务中。

小结

在一个单块系统中，各个组件在同一个进程中运行。它们相互之间的通信，要么通过方法调用，要么通过函数调用来进行。将一个单块系统改造为若干微服务的最大问题，在于对通信模式的改变。仅仅将内存中的方法调用转换为 RPC 调用这样天真的做法，会导致微服务之间产生繁琐的通通信，使得系统表现变糟。取而代之的是，需要用更粗粒度的协议来替代细粒度的服务间通信。

特性五:“去中心化”的治理技术

就是说各个全功能团队能自主的选择技术栈而不是上面定标准下面执行，上面定的标准很容易成为具体实施人的障碍。

特性六:“去中心化”地管理数据

相对于单体应用通过事务来保障的强一致性，微服务架构更强调在各个服务之间进行“无事务”的协调。这源自微服务社区明确地认识到下述两点，即数据一致性可能只要求数据在最终达到一致，并且一致性问题能够通过补偿操作来进行处理。

特性七:“基础设施”自动化

在微服务语境下,开发、测试、运维等不同角色可以随需动态获得完整的环境(如 dev，test，staging 等等)，从而统一环境、标准化研发实践、规范化研发能力，并且给研发提供体验更好的开发环境。要达到这样的目的就需要基础设施自动化的相关技术。

特性八:“容错”设计

因为各个服务可以在任何时候发生故障，所以下面两件事就变得很重要，即能够快速地检测出故障，而且在可能的情况下能够自动恢复服务。

特性九:“演进式”设计

有人觉得微服务或许很难成熟起来，这当然是有原因的。在组件化上所做的任何工作的成功度，取决于软件与组件的匹配程度。准确地搞清楚某个组件的边界位置应该出现在哪里，是一件困难的工作。演进式设计承认难以对边界进行正确定位，所以它将工作的重点放到了易于对边界进行重构之上。

总结

上面内容很多都是从别的地方 copy 过来的，也有不少我自己的观点，总的来说微服务不是银弹，要实施微服务也需要诸多考量。本文也是想给出一些看法，希望能引起大家的一些思考。大部分时候结论并不重要，重要的是思考过程，是自己在实践中不停的独立思考这些想法对不对，适不适合自己的过程。

更新于20201208

  • 全功能团队我觉得主要是统一大家的利益目标，团队有成效的时候大家都能享受到对应的回馈，之前听脸书的产品经理说他们研发工程师的绩效是和对应产品的成效挂钩的。
  • 老马说的微服务更多的是在国外落地的，一般一个应用一个数据库，但是在国内很多的是类似中台这种落地方式，具体可以看看刘超老师的传统行业转型微服务的挖坑与填坑