后SOA之未来

SOA 哲学 思考的艺术

本文阐述的不仅仅是技术，更是一种思考方式，是哲学。

历史

上一节，讲哲学与历史的时候说过,系统的进化过程:

SOA 发展

• 这个时候需要合理的划分服务,尽量以大模块服务和公共小服务。

何谓一个大模块服务呢?［以下均以Java系统为例子］
比如 coredb[UserDAO.java,MailDAO.java,MemberDAO.java.java....]作为一个CoreDBService服务,

业务X本来只想用下 UserDAO.java里的User信息,不巧却因为使用的是CoreDBService而看到了一堆其它的DAO模块.......(有时候我可能根本不想被你看到－－－－> 这个时候，可能要再把UserService剥离出来了)

然后剥离后,现在业务B 还是要查User信息,这个时候我们就去查询UserService这个微服务. 但是呢UserService的接口

interface UserService{
   boolean createUser(User user);
   boolean updateUser(User user);
   boolean deleteUser(User user);
   User selectUser(int id);
}

本来呢，我只想要查，但是你却给了我增删查改的权力,
人一拥有权力就会犯错。
虽然说内部的人，我们一般是保持信任的，所谓用人不疑，疑人不用。都是内部系统，我就认可你操作所有服务和服务器的合法性。

但呢就要人有时候犯浑或犯贱，我明明不给你这么多操作，你不就没有机会去犯错吗，为什么要在系统里留下一个隐患呢，这个时候是否可以考虑下 改变下服务调用的方式？
eg:
假如是这样调用的
{
"service":“UserService”,
"method":"queryById",
"params":"2001001"

}
那么对业务B 来说 我只给你上面一个json串去调用获取你需要的User信息，你就不知道如何更新与删除，而避免一些不必要的事情.

这种情况感觉是这公司得多大啊，要防到这种地步,也没见人这么做过，这里只是提供一种思路或偏见。

SOA 灾难

唉 全奈自己动不动就要把这抽离出来，业务越多越杂，要抽离的就越细化，服务就越多

我们需要明确一点: 服务分的越标准 越精细 耦合越小,服务数量越多.这一点是理所当然的,

但人性是贪婪的, 我们往往既想服务或系统间的耦合越小越好，又不想服务的数量变得旁多无比，我告诉你 这是 "不可能的[1]"

接下来就会发生：

1. 服务爆炸（太多）
2. 内存爆炸 (消耗太多)

那么解决方案就是：

1. 买机器。

   钱的问题，就不说了。

2. 或者 想办法省内存.

   以Java系统为例,各个服务中有一堆jar包都是一样的,比如common-lang,druid,json等jar包, 这些在各个系统里反复加载多次，可以考虑加载一次，一个机器上的所有服务共享，参见classloader加载类的原理，应该是可以做到的。

但是呢，服务耦合小，服务数量又不会太夸张，真的做不到吗？

我想起一个伟大的哲学家曾经说过： 看起来合理的事，反过来也必须合理。如果不合理那么就是概念有问题，或者是思路不对，或者思考的角度不对。因为没有生病所以健康，那么正式因为生病所以健康也是合理的。

我们曾在纠结 在业务里分MVC好呢，还是MVC里划分业务好呢，这里你说怎么好就好，你说怎么不好就不好，我们之所以无法解决这个问题，或许一直是思考的角度不对，抽象点来说这是一个二维世界里的矛盾，后来出现了RPC和SOA这种三维产物 将MVC与业务整在一起抽离成服务提供出来。

但现在SOA的这种矛盾，是在三维世界里的，是不是应该有个四维的什么东西来解决SOA里的矛盾呢，

这个四维应该是包含了三维的服务属性 ＋ ？？？？

向后看一片迷茫，往前看（ALL IN ONE）所有东西都揉杂在一起的原始系统。。。。。。联想到当前还算火热的新新事物Docker,
我不经冒出一个奇怪的念想：

幻想中的四维世界：

各个服务更像是组成容器的组件,服务在容器内部单独部署，不同容器之间的同一个服务互不关联互不影响。

更有一种 容器即系统的概念。
定义一个系统所需要的服务组建和组建之间的关联与耦合，来创建容器或者叫做一个系统。

每一次组件（服务）的更新，各个容器（系统）都需要重新构建一次，重启一个重启的整个生命周期。完全强耦合。

根据哲学推论，正是因为耦合越来越低，所以耦合强应该可能会成为它新的一维的条件。

以上权当胡说九道，只是一种思考问题的方式。