浅谈Service与Business

        在与人做技术交流时，发现有很多人把Service与Business混在一起来谈论，有很多人甚至认为他们是一个东西。在我看来，他们虽然有时代表一样的概念，但这是在很小的应用中的情况，也就是说那是并没有所谓business的概念，业务层都推在service中，因为很多人都停留在这层，所以会对此无感。

       在我看来，business是业务层，他是常常变化的，所不定业务场景每天都在变，或者说他随时会被在平台系统中个摘下来，不再用了。而servicec层是一个并不常常变化的业务层面，他是一个稳定的板块，核心的，是无法摘掉的。这样来比如：service就像一棵大树的主树干，business就像大树的叶子、树枝，他是可以被摘掉或重新生长的，而service是大树的主树干，他也会发展，但确实稳扎稳打的向内部发展，让自身更加稳定、根子更加磐实，不可撼动，不可代替的。

在软件工程的项目设计中，最理想的状态时把business做到一种可以插拔式的业务形态，而service就像一个主电源线。这也许是如今讨论的如火如荼的soa应用的初衷。

soa要把业务给拆分，主要是为了做到一下几点：

1）程序写着写着，发现项目每次发布项目上线、启动项目太慢了，以前是小程序的时候，上线和启动的时间2分钟，当程序变大了，就需要1-2个小时甚至更久。上线发布就成为了一个问题，这不得不到了给程序瘦身的地步（这是soa实现最明显的一点）；

2）知道要拆分系统，让他上线发布变的更快，但是，应该如何去拆分呢？这就是service与business的真正区别，我们拆分系统应该要有一个主线，这就是service, serivice 一般会包含一个平台的基本功能的一些骨架，比如权限、用户、监控这写都是模块就是service的代码，他们在完成、并趋向稳定后基本不会有改动。business 的业务就像秒杀活动的业务、团购活动业务，这些都是一些business模块，他们可以对接到service的主干平台系统中，也可以在不玩什么推广活动，就能随时把他们卸载下来。当然，世事无绝对的划分，有时我们也会遇到一些灰色的模块，不太好定义他们是在主干好，还是在分支的好。比如支付系统、订单系统、日志系统、财务系统等，这种系统做完后改动空间可能也不大，但又和主干系统紧密结合的，这就很难办，建议先做成分支，后拼凑到主干系统中，成为一张拼图。

3）soa现在知道要这样拆分了，但应该如何让主干具有那么强的兼容性呢？提供各种插头给business模块来扩展，就像spring一样，spring是主干，springMVC、 spring-data等就像business一样，具有插拔性。