背景知识

微服务软件框架

微服务（Microservice）这个概念是2012年出现的，然后2014年开始受到各方的关注，而2015年开始成为了热门。

在国内，也是从2015年开始，各大互联网公司开始涉足微服务软件框架，比如阿里巴巴开始使用Spring Cloud，并在Spring Cloud的基础上，衍生并开源出一套全新的微服务框架 - Spring Cloud Alibaba。同时阿里巴巴还开源了一套Dubbo框架。还有腾讯的TARS、百度的 bRpc。

我也是在2015年开始接触并实践了谷歌的gRPC、Facebook的Thrift。

微服务架构模式

企业应用架构模式从最初的单体架构，后来发展为SOA（面向服务）架构模式，再后来从SOA架构模式进化出当下最盛行的Microservices（微服务）架构模式。

企业应用架构模式变迁

本文要说的是微服务架构模式，不是微服务软件架构。主要是关注一下微服务架构模式所倡导的一些核心价值观。希望从事软件架构设计的朋友，可以从这些价值观里面，学习到这种模式的思想和理念。从而可以从各种微服务软件架构里面走出来，不在纠结于用哪种架构体系，用哪个工具链。

从事这么多年互联网的软件行业，我们一直是在跟随着大师们的思想在前进，比如曾经风靡一时的面向对象(COM、DCOM、CORBA)、23种设计模式、UML(统一建模语音)、SOA（面向服务）、Xp、Scrum、微服务、Devops、IaaS、Paas、Saas、Faas等等。但是我们一直被陷入在各种开发环境、开发语言，各种开源的框架系统之中，反而忽略了大师们的思想。

曾经我问过一个做了两年Coding的同事：什么是类？什么是对象？
他竟然不能回答。（ 难怪他的代码总是质量很差 :) ）
不深入的理解类和对象，如何可以定义出一个优雅的类，如何可以管理好一个对象实体的生命周期呢？更别说业务的扩展性了。

要想理解大师们的思想，最核心的就是要理解大师们所要表达的价值观。我罗列了一下微服务架构模式的核心价值观。如下图：

书蛙老牛

我主要从两个维度罗列的，一个是：

组织架构

Martin Fowler大神

Martin Fowler，1963年出生在英格兰的沃尔索耳，在1994年，移居到了美国。
他是国际著名的OO专家，也是敏捷开发方法的创始人之一。

微服务架构模式，是Martin Fowler首次在一篇文章里面提出的，他提出这个模式和他的敏捷开发思想也是相通的。因为在组织架构上，这两种思想的核心价值观基本上是一样的，具体如下：

• 服务意识
  根据微服务来划分团队，可以增强团队的服务意识，因为这个服务明确分配给你们，你们就需要提供好这个服务。
• 产品思维
  每个微服务都是根据领域来划分的，负责独立的一部分产品业务，每个微服务也可以理解成一个子产品。
• 权利分散
  因为从产品业务层就开始考虑划分微服务，然后分配资源，因为权利来源于资源，所以相当于把权利分散到了各个微服务。
• 小团队
  团队多小合适，有一个“两个披萨原则“，意思是不能多于够吃两个披萨的人数。小团结易沟通协调，效率更高。
• 独立自主
  因为资源权利下放到微服务团队里面，团队就有一定的自主权，这样更可以发挥团队的积极主动性。
• 责任明确
  权利和责任是成对出现的，有权利就意味着要有责任，这个是非常明确的。
• 全栈式
  由于微服务是包含整个业务的，所以可能会应用到各种技术，需要团队成员会多种技能。
• 自由
  自由和独立自主是对应的。
• 共享
  这个有两个层面，一个是需要对外共享这个微服务；另一个是团队内部的共享。
• 协作
  小团队，更注重协作。

还有一部分价值观，属于微服务本身的，如下：

微服务

• 规范
  由于一个大应用划分成很多微服务，这就需要有一套规范，来共同约定。
• 文档化
  微服务的目标就是被调用的，首先微服务的使用文档是必备的。
• 可用性
  微服务功能职责单一，具有更高的可用性。
• 开放协议
  微服务可以被任何应用来使用，因为微服务具有开放的协议，只要按照协议来调用就可以了。
• 扩展性
• 安全性
  微服务是独立部署、独立运行的，也具有独立的安全认证机制。
• 粒度小，松耦合
  微服务专注于应用解耦。
• 移植性
  微服务是独立部署的，具有可移植性。
• 隔离性
  隔离性也是来自于独立部署，独立运行。
• 自动化
  微服务架构模式提倡自动化测试、自动化部署、自动监控。

批判性思考

微服务这个思想从2012年正式提出到现在已经8年的时间了，这期间被广泛的传播，相应的软件架构和技术也得到了广泛的应用。这里提出几个需要思考的问题，通过这几个问题，我们反思一下我们曾经应用过这种架构模式的产品，然后反思一下这个模式现在是不是还适应互联网软件行业的发展，以后会不会出现更出色的思想框架来替代它。问题如下：

• 你和你的同事们，都认同这些价值观吗？还是只认同其中的一部分？为什么不认同？
• 我知道很多应用案例，都是应用了开源的软件框架来实现后台功能的解耦，前端业务和组织结构层面上并没有采用，你知道是为什么吗？
• 你知道都有哪些微服务架构吗？你知道它们分别适合哪种应用吗？
• 针对你使用过的应用，你认为采用这种模式是最好的吗？还有没有更好的替代方案呢？
• 你知道”函数式“架构模式吗？，你认为这种模式怎么样？和微服务架构模式比较呢？

函数式架构模式脑洞

1、把所有的业务功能拆分成一个一个函数，每个函数定义好输入和输出。每个函数都是完全独立的。
2、然后根据这些函数划分团队，或者不要团队，直接分配给每个人，然后这个函数独立部署、独立运行。
3、针对每个业务功能，会有一个函数的调用序列
4、请继续。。。。。。