微观架构和宏观架构论

http://blog.csdn.net/jdream314/article/details/18041391

微观架构和宏观架构论

     以下内容纯属自己YY，纯属自己更加自己经历有感而发。希望大家不要较真，如有误导，欢迎拍砖。以下想法和理解仅供参考，还望不要误导。

    一般都知道架构师们总是将问题进行抽象，从而将整个系统搭建在一个抽象基础之上，他们往往会定义一些接口或者实现一些默认机制，然后具体内容交给下面的我们这些码农们。一个好的架构，不是越抽象越好，也不是使用的模式或者规则越多越好，而是简单易懂、结构清晰，不是为了让我们下面一群码农们像雾里看花一样看待他们的架构，这样的架构只能说是为了架构而架构。架构师们很NB，工资高，写的代码少，会议多，整天是各种架构会议、管理会议、组织会议……他们对下面码农们说的最多的就是：我是站在全局看的。这句话听上去感觉是宏观的，但是里面包含两个方面。

    一、微观，站在业务的角度来认识系统的架构，他是一个微观的概念，比如说：一个系统应该包含哪些模块，模块之间的关联关系，系统运用哪些模式或者规则来设计。这些东西都是基于业务来进行设计的。他可以不考虑外部的网络部署，服务器搭建以及外部依赖等因素。这些都只是站在对业务的实现来进行考虑，如何更好的实现对应的业务，从而使得对该业务系统能够更好的支持其扩展性，容错性以及可维护性等等，这就是微观的架构，为何是微观，原因是由于他关注的是业务内部的规则，这种架构依赖了他对应的业务，可能不同的业务那么其架构会有所不同。比如说：现在要实现一个CRM系统，那么架构师站在微观的角度去分析，需要知道CRM系统内部的业务规则，以及各个子业务之间的关联关系，从而可以设计出复合CRM系统所具备的功能。这里所需要首选就是需要了解CRM的业务规则，而不是考虑CRM的其他外部因素。微观之所以微观，是因为它是站在业务内部的细节，而不考虑其外部的环境。

   二、宏观，通过上面微观的分析，应该知道宏观应该是什么内容。宏观的架构，则是站在系统所部署的环境以及外部依赖条件等因素。为何需要考虑这些内容呢？这些不是运维可以搞定的嘛？任何业务的系统都需要一个部署的环境，可以是甲方拟定或者是软件生产商规定，都必须规定一个系统的部署环境。比如说：系统A和系统B之间存在依赖关系，或者可以理解为A需要从B获取信息。A从B获取信息可以是被动也可以是主动，这个设计需要考虑A和B的部署环境，比如，A是部署在内网而B是部署在外网，那么需要A主动去请求B获取信息，因为A是在内网，没有对外的IP，B根本不知道A的存在。所以这个时候在系统架构的时候，没有考虑这个因素，而恰好是设计成为B主动推送给A那么，这个A系统基本上属于瘫痪状态，或者说A系统和B对接模块需要重新设计。这种架构则是站在整个业务范围之外来对整个系统进行考虑，这种架构收到网络架构，外部依赖以及服务器架构等因素的限制。从严格意义上来将，系统应该不要过分依赖于外部因素，特别是服务器。比如：一个系统在设计的时候就对tomcat的管理比较紧密，那么可能在初期发现不了问题，如果当运维升级或者tomcat不是免费了（这个或许不可能），那么当前这个系统就会被绑架式的进行了约束。那么这个时候，需要架构师站在更加宏观的角度去审视整个系统，从系统以后所要生存的环境来看待这个系统而不是简单的实现某个业务逻辑。

    此处例举一个本人经历过的例子来归纳一下上面所描述的宏观和微观架构。Session共享是作为互联网应用应该具备的功能。前段时间，由于项目比较多，每次升级都需要通知客户暂停操作，然后进行重新部署升级，导致运维发布很纠结，用户体验也很蛋疼。于是运维建议做一个session共享的组件，后端进行集群部署，都进行升级的时候，用户将会自动跳转到另一个服务器上进行操作，而无需再次登录。这样可以在用户不停止操作的情况下进行后台升级。于是本人就试着动手做做。已经上面宏观和微观的概念，现在站在微观的角度来进行分析，考虑session共享的具体业务规则，session共享是将用登录的会话信息进行共享，从而在进群部署的环境下面用户可以无缝的跳转与各个后端服务之间。那么这里唯一要做的就是将用户的会换信息进行共享，也就是将会换信息存储在一个公共的存储介质上，本人采用了Redis缓存服务进行存储用户会话信息，则在用第一次登录成功后，将用户的会话信息存储到Redis缓存中，在每个应用中都有一个Filter，过滤用户所有的请求，该Filter做的第一步便是从Redis缓存中获取用户会话信息，如果没有表示之前没缓存过，进行登录操作，否则将缓存的会话信息复制到session中进行后续的操作。基于这种机制可以实现多太服务器的session共享。这个是站在微观的架构，为的是实现这一业务逻辑。

    那么站在宏观来考虑，基于tomcat的session共享有很多插件，这种插件对于部署在tomcat的应用来说可以不需要依赖任何组件和进行任何调整即可以拥有session共享，但是这里就限定了应用部署的环境，必须是tomcat，如果换了新的部署环境，是否有对应的session共享插件这个不可而知。所以基于tomcat来做session共享插件是一个不可取的方式。因为session共享是需要做成一个公共组件，既然是公共组件就不能要求应用在使用该组件时，规定应用部署环境，这就不是公共了。从没看过spring，struts，hibenate或者是ejb对应用使用的部署环境进行限定吧。

   上面是根据实际情况对宏观架构和微观架构进行了归纳以及演示。虽然真正要实现session共享是不依赖session来进行实现，但是由于当时所有系统确实对session的依赖比较紧密，所以暂时考虑采取上面那种方式进行比较牵强的实现。

以上是全部内容，欢迎拍砖………