架构发展趋势以及 d2js 的未来

目前架构有几个热点方向：微服务, dubbo, Faas，还有 TiDB。

现在开发模式是前后端分离基本成为行规。

应该说以大部分企业业务量级、人员规模来说，要去和淘宝等大厂去对标是非常傻的。对大部分企业来说 LAMP 就够了，要是聪明点把 M 换成 P，那 ElasticSearch 什么的就都省了。

那么这些企业为何要跟风呢？ 原因很简单，确实他们有爆发的可能，而一旦爆发后IT建设扛不住压力，就会导致流失的客户再也不回来。人人网曾经有过这样的故事，最近也见过几个这样的案例。可伸缩架构对他们来说的确非常重要。

微服务

微服务架构的优势在哪儿？

我曾经接触过一个死活要搞微服务的公司。他的看法是，项目大了每次部署都要花很久打包，要升级就得重启服务器，所有服务都要停，所以微服务是必须的。

当然，他肯定不知道 d2js 这种扔上去就能完成部署的技术，相似的 php 等等应该也不太了解。

其实微服务这种技术充满了缺点，它把一个产品变成了一堆产品，把内部问题变成了外部问题。上微服务更多的是一个管理需要而不是技术需要。

微服务解决了哪些问题呢？

首先，微服务拆分简单粗暴，在实践中所谓架构师只要若有所思的把传统意义上的功能模块切成微服务就行，一个项目就这样变成了好几个。

这样新招来的十几个人分两个三个组，各自领一个微服务去开发。库也不共用，也不需要共享业务级别的类库。前期成本为零，开发完了靠沟通磨合完成服务对接。

各个项目互为黑匣子，这样每个组想用什么技术用什么技术，各有各的 POM，包冲突什么也不存在了。既然模块功能单一，包名是叫 com.nb.service.payment 好还是叫 com.nb.payment.service 好也不用思考了，毕竟你手里只有 payment。

这个角度微服务的擦屁股版就是所谓中台。

微服务上线后出什么问题也很好查，先找到问题在哪个微服务，揪出相关责任人就行，这样一来其他人就不会被午夜骚扰。

由此可见，微服务其实主要解决的是管理问题，或者说开发模式问题。

微服务的问题有哪些呢?

1. 一旦采用微服务，许多调用就变成远程调用，成本很高，协调成本也很高。
2. 微服务对数据库的治理采用一个服务一个库的模式，也导致更高的数据库维护成本，只能便宜云厂商。
3. 采用微服务后, 程序员越来越沦为 coder, 对产品全局的把握越来越低下
4. 协调成本很高, 从以往靠代码变为靠文档. 收到接口首先要验收一遍.
5. 必须上笨重复杂的分布式架构，系统复杂性度大幅上升

dubbo、SpringCloud 等

由于微服务拆分把任何小系统都变成了若干个分布式系统的邦联, 导致以往只有跨系统边界才有的分布式事务等等成为必需品, 分布式架构, TCC, Raft 等等成为显学.

为此就需要引入一些能实现 TCC 的模块, 这就是 dubbo, SpringCloud 等。

这些技术给我带来的感觉特别重，我的预感是会像 EJB 一样过时，让人很难深入进去。

FaaS Servless

函数即服务，和 d2js 的理念很相似。FaaS 彻底把作为业务的主体（业务函数）和作为容器的主体（单节点或分布式系统）彻底切割了。

平台归平台，业务归业务。这是 d2js 设计一个主要初衷。

FaaS 的事件/函数模式和 d2js 也很像，可以说 d2js 往前走一步就是 FaaS。在实践中我也用 crontab 调 URL 的方式实现定时触发 d2js 任务函数，也用 activiti 调用 URL 来触发 d2js 流程处理函数。

相信未来应该属于 FaaS。d2js 应当迅速演进到 FaaS。

FaaS 能不能覆盖所有业务场景呢？无部署的模式不适合一些重量级的算法复杂演算繁多的应用。

Q. 能不能把这种应用的接口视为 F，程序主体视为依赖包呢？
A. 这么理解是不合适的，这些所谓的依赖包需要追随 F 部署，不具备稳定性，不能视为一种东西。并且这些包对环境依赖较高，有的需要 GPU，有的需要自己的 db, 有的需要文件存储，不像 F 可以轻易的迁移。所以像这些服务还是用微服务来实现会比较好。当然，一旦它们能中立的定型下来，转为`F + 依赖包`也未尝不可。

目前的 FaaS 主要问题有：

1. 函数粒度太小，一个函数即使加上一些 annotation，能表达的东西也是很少的。由于部署不在一处，这种函数和其它函数之间不能简单的互相引用。这和 C# 只有闭包而缺乏匿名内部类的问题相似，单个函数无法形成 bundle，无法形成一组接口这样的概念，组之间需要共享一部分组内数据。
2. 分布式事务缺失。我看不到容器对分布式事务有任何支持, 因为编写 F 都不需要给相应实现.

TiDB

TiDB 是我通过 LSTM Tree + RDBMS 找到的。PG 也有一个实现，叫 VidarDB. TiDB的应用在国内已经非常广泛了， VidarDB有待检验。

可以说，TiDB 彻底解决了分布式数据库的问题。分布式架构最终形成分布式平台，而不是人人都研究分布式，这才是正道。

如将 LAMP 模型里的 M 换成 TiDB，是不是可以解决今天的问题呢？

A 现在是 NGINX
M 现在是 TiDB
P 现在是 d2js

LNTD 这样的组合，要应付大并发，还需要做这样的改进：

1. d 所依赖的容器应更换成 vertx 或其它高性能框架，这样 RPS 可以做到极高
2. 其次，这种容器最好是分布式的容器，这样 d 就不用担心伸缩性
3. 同样需要 cache 降低数据库压力，需要 MQ 用于削峰。

当然，配合分布式容器，d2js 也应改进 TCC 特性，以及更加专门 FaaS 事件驱动绑定。

有了这些改进，d2js 会是一个非常好用的 FaaS 实现方案。