系统架构设计和应用架构设计（整理自网络）

应用架构&系统架构:  系统架构差不多不都是那一套, F5+squid+nginx中层代理集群+（nginx静态文件读取）+web服务集群+db集群+mamcached集群+（异步队列集群） 差不多也就这么多了，对了还有个CDN，不过是访问量非常高且企业有实力的才会用CDN，毕竟费用也挺贵的，不过我主要还是关注，应用程序层面的高可用高 并发的开发。。。

 

 

系统架构和应用架构的区别，系统架构设计主要关注对非功能性需求的实现方式。比如数据量多大，海量数据如何处理，数据的存储、检索如何优化，数据库 是否要分区，数据库如何优化。并发性多大，并发访问的瓶颈是在IO？数据库？还是应用服务器？，是否需要集群？硬件集群还是软件集群。安全性的要求有多 高，响应时间的要求是什么等等。

       而应用架构设计则主要从业务层面考虑系统的功能边界在哪，系统需要划分成多少个模块，每个模块之间的接口和调用关系，采用什么样的技术框架等。

       应用架构设计有几个核心的原则，开放-封闭原则，即对扩展开放，对修改封闭，这也是考核一个架构是否良好的一个标准。高内聚低耦合原则，尽量将功能相关的 内容组合在一起，封装后对外提供接口。封装变化原则，越是可能发生变化的地方越要进行处理和封装，将变化的影响限制在一定范围之内。平衡性原则，因为对系 统的很多要求是相互矛盾的，因此架构设计需要平衡多方面的要求，最后折衷考虑设计方案，比如性能和灵活性就常常是一对矛盾的要求。

       比如，如果我们某个软件系统需要用到工作流，那在应用架构设计时就需要考虑以下问题：是自己独立开发工作流组件，还是使用第三方的成熟组件？是采用嵌入自 己代码的方式，还是采用远程接口调用的方式？在数据库的数据层面是否要做交互和直接访问？如果是使用第三方组件，那在架构设计时就需要考虑到封装变化的原 则，即将来如果替换成别的产品，是否需要大量改动，所以架构设计时最好是建立一个封装层，业务层调用封装层的接口，而封装层来封装调用工作流组件的接口， 可以采用Facade模式，也可以采用Adapter模式。

       我们做软件项目时经常有一个体会，就是需求总是在变化，我们通过良好的架构设计可以封装好一部分的变化，剩下的变化就需要靠可扩展性来支撑。可扩展性是软 件开发中经常遇到的一个词，我认为一个软件的可扩展性体现在两个层面，一个是设计可扩展性，一个是运行可扩展性。

       设计可扩展性指的是在架构设计的时候，根据高内聚低耦合的原则将系统充分模块化，然后在每个模块的内部，根据开放-封闭原则来设计这个模块的架构，即达到 的效果是如果将来需求扩展，那我只需要按照原有的结构样板扩展增加新的代码模块就行，而不需要修改原来已经写好的那部分代码，或者修改量很少，这就是开放 -封闭原则，对扩展开放，对修改封闭。所以，设计可扩展性能达到的效果是需求变化时，通过程序员扩展代码来实现。

       而运行可扩展性，指的是需求变化时，系统的用户可以通过配置的方式让系统支撑新的需求，不需要程序员修改任何代码。这种功能对设计的要求很高，需要在架构时做有针对性地设计，比如采用元数据，采用数据模板，采用行列变换等方式。

       举个生活中的例子，比如手机。手机有各个硬件配件，比如屏幕、键盘、电路板、摄像头、外壳等等，这些配件都做到了模块化，高内聚低耦合，手机生产商可以很 方便的把某个配件的供应商换为另一家，因为配件的接口定义好了，内部实现是可以替换的。如果手机设计得好，那用户需要新加一个功能时，比如手电筒功能，厂 商就可以直接在原来的手机型号上扩展这个功能，加上一个迷你手电灯泡配件，而不会影响其他已有的配件功能，这个就是开放-封闭原则，也达到了设计可扩展 性。另外，手机中的SIM卡插槽设计的时候就考虑到了不同用户的需求，做成了运行可扩展性，允许用户自己随意更换SIM卡，你可以从移动的换成联通的，也 可以换成别人的，这种需求的变更不需要把手机返厂修改，用户自己就可以做，就相当于实现了运行可扩展的功能。

       具体在一个项目中哪些功能遵循设计可扩展性，哪些功能遵循运行可扩展性，就需要分析各项要求了，一般来说，越支持运行可扩展性系统的灵活性越高，但性能可 能会下降，系统的可维护性可能也会下降，什么都做得那么灵活是不现实的，需要折衷考虑，这就是架构设计的平衡性原则。