第二类依赖则可以更进一步，将其放到独立的进程中。现在稍具规模的系统，登录、注销功能已经从应用中脱离而出，要么采用SSO的方案来进行登陆，要么干脆代理给别的登录系统。大连微信在线支付开发团队在开发过程中发现，缓存的读写实际上可以放到独立的进程中进行（而不是类似 EhCache 的方案，直接运行于所在的环境中），于是发明了现在鼎鼎有名的Memcached。我们之前进行一个项目，发现支付模块完全能够独立出来，于是将其进行隔离，形成了一个新的、没有界面的、永远在运行的系统，通过 REST 处理支付请求。在另外      一个出版项目中，我们发现编辑编写报告的过程实际上与报告发行过程虽然存在类级别的重用，但在业务层面是独立的。最终我们将大连微信在线支付开发报告发行过程做成了一个常驻服务，系统其他的模块通过MQ消息与其进行交互。

      致远服软认为：http://www.soft8.com.cn/这一解决方案应该不难理解。与解决方案1不同的是，这一方案更多 的是要对系统进行面向业务层面的思考。由于系统将会以独立的进程来运行这一模块，在不同的进程中可能存在一定的代码重复。例如Spring同时存在于两个不相关的项目中大家觉得没什么大不了的；但如果是自己的某  个业务组件同时在大连软件定制二次开发项目的两个进程中出现，许多人就有些洁癖不能接受了（题外话：这种洁癖在OSGI环境中也存在）。

      这里需要提醒的是：当处于不同的进程时，它们在物理上、运行时上已经彻底隔离了，必须以进程的观点去思考整个架构，而不是简单的物理结构。

      从单进程模型到多进程模型的架构思维转变也不太容易——需要架构师有意识地加强这方面的练习。流行的.NET和Java世界倾向于把什么都放到一起，而Linux世界Rails/Django则能更好地平衡优秀产品之间的进程协调，例如Memcached的使用。

      另外，现在多核环境越来越多，我们与其费尽心思在编程语言层面上不如享受多核的好处，多进程能够简单并且显著地利用多核能力。

      现在将眼光看更远一些，想象一下我们在做一个类似于开心网、Facebook、人人网的系统。它们的共同特点是能够接入几乎无限的第三方应用，无论是买卖朋友这类简单的应用，还是绚丽无比的各种社交游戏。神奇的是，实现这一点并不需要第三方应用的开发者采用跟它们一样的技术平台，也不需要服务端提供无限的运算能力——大部分的架构由开发方来控制。

      在大连微信在线支付开发应用中实现这个并不难，这其中的秘诀在于：当用户通过Facebook访问某个第三方应用的时候，Facebook实际上通过后台去访问了第三方应用，将当前用户的信息（以及好友信息）通过HTTP POST送到第三方应用指定的服务网址，然后将应用的HTML结果渲染到当前页面中。从某种意义上讲，这种技术本质上是一种服务器端的mashup（详情参考InfoQ文章）。