标签：防火墙 软件 集群 高新技术 数据流 pid 原则 能力 性能
随着然健系统规模的增加，计算相关的算法和数据结构不再构成主要的设计问题； 当系统由许多部分组成时，整个系统的组织，也就是所说的“软件架构”，导致了一系列的新的设计问题。
架构设计本身是为了解决软件的复杂度。
架构设计并不是要面面俱到，不需要每个架构都具备高性能，高可用，高扩展等特点，而是要识别出复杂点，然后又针对性的解决问题。
“业界A公司的架构是X, B公司的架构是Y, 两个差别比较大，该参考哪一个？” 答：理解每个架构方案背后所需要解决的复杂点，然后才能对比自己的业务复杂点，参考复杂点相似方案。而其中的关键点就是要明白什么会带来软件复杂度.
为了高性能, 选择复杂的模型(比如多台计算机集群), 会提升软件复杂度.
"高可用" 系统无中断的执行其功能, 本质上都是通过"冗余" 来实现高可用.
可扩展性, 系统为了应对将来需求变化而提供的一种扩展能力， 当有新的需求出现时，系统不需要或仅需要少量修改就可以支持，无须整个系统重构或重建。为了应对变化实现可扩展:
1) 系统需要拆分出变化层和稳定层
2）需要设计变化层和稳定层之间的接口
comment: 安全，防火墙基本功能是隔离网络.通过将网络划分不同的区域，制定出不同区域之间的访问控制策略来控制不同信任程度的数据流.
规模, 规模越大, 系统越复杂.
合适原则, 不一定高新技术就一定好
不是什么东西都要自己实现，多使用开源的成熟的组件
资源问题，钱，人力，时间等等，没那么多人，却想干那么多活，是失败的主要原因
简单原则，架构越简单清晰越好， KISS原则。（keep it simple, stupid）
演化原则，系统是随着业务变化不断变化的, 架构师时刻提醒自己不要贪大求全，或者盲目照搬大公司的做法。而应该是认真分析当前业务特点，明确业务面临的主要问题，设计合理的架构而快速落地以满足业务需要，然后再运行中不断完善, 不断演化架构.
首先, 分析系统的复杂度.
其次, 按照当前成熟的流行的架构, 作出预选架构方案.
然后, 从 性能，复杂度，成本，可扩展，可用性 等角度环评每个方案(可考虑哪个方面优先级更高, 比如阿里不差钱, 那成本优先级可能低一些)
之后, 设计详细方案. 比如确定用 Nginx 做负载, 那么 Nginx 的主备怎么做。(到这步具体细节可以大家一起讨论)
标签：防火墙 软件 集群 高新技术 数据流 pid 原则 能力 性能
原文地址：https://www.cnblogs.com/moveofgod/p/12255259.html
