弹性架构

转：http://www.dongcoder.com/detail-1165658.html

架构使得我们的软件如同积木一样，各司其职，但却又相互连接，这是我们在谈架构时常会联想到的，然而，我们的开发工作并不能完美的套用积木的特征，比如积木的一部分坏了，我们可以把坏的那一块换掉，而在我们的开发工作中，往往牵一发而动全身，因为各个模块是通过信息、数据连接在一起的，它并不是一个客观的物理结构生生地卡在那里，而是一种抽象的连接方式，因此，在替换某一模块时，我们常常要考虑会不会导致其他的部分出现问题，而这个考虑多数情况是多余的，因为几乎都会出现问题。

　　那么有没有把影响降到最低的办法呢？这篇文章就讲了这个问题，分层架构可以让我们有意识的做一些切分，但还是取决于我们切分的大小。这时，更好的方式就呼之欲出了，在软件中，有两种不同的连接方式，“异步”和“同步”，在这里，我们就要用到异步，在软件的工作过程中，一个模块不需要考虑其他模块的执行，而仅仅保证自己的数据能够传输给下个模块。

　　在这篇文章中举到了一个例子：事件驱动架构。

　　平时常见的MQ、本地消息表等运用于数据传输的中转环节，就是事件驱动架构的思想体现。

　　而事件驱动架构又分为两种实现方式，一种是中心化的，一种是去中心化的。

　　中心化是指在这个场景中，拥有一个管理者，它编排事件，但不需要知道任何业务逻辑。在这种模式中存在三个过程：事件产生、事件调停、事件处理。这种模式的好处是我们可以清晰地，直观的看到其中的流程，有利于这个过程的监控。而问题在于这种模式实现起来需要数据的一致，因此要投入的精力也会因此增加，因此，在处理不算特别庞大而又稳定的场景时，常常要使用去中心化的方式。

　　去中心化就是把事件管理者的任务交给了开发者事先写好的任务代码中，各个模块只需要知道下个模块，数据的方向以及参数即可，这种做法使系统更加流畅，也更加接近 我们前文讨论的期望。

　　在云时代架构发表的这篇文章中，也讲了微内核架构的思想，总的来说就是明确一个内核， 将其他部分视为插件，插件们彼此独立，而内核又知道如何找到、使用插件。用一个不太恰当的比喻。在古代，军队有最高的武力系统，但他们为了钱给皇帝工作，但他们不知道金库在哪里，而守着金库的人摄于兵权不敢私自取盗，这两拨人又被分隔开，没有相遇的条件，这种信息的不对称完成了皇帝的统治。在这个例子中，皇帝就好像内核，军队和金库看守者包括大臣们就好比插件，皇帝所掌控的信息使其可以调度和分配插件的位置甚至更换插件。

　　以上是我的感想。还有很多不足和不懂得地方。