关于架构的理解有很多人会有误区，认为架构是一个很大的整体框架，像安全架构就是综合所有安全设备的一个框架，其实并不是这样，架构是为了设计系统的元件如何划分、元件之间如何发生相互作用，以及系统中逻辑的、物理的、系统的重要决定抉择，负责不同层次上的逻辑架构、物理架构、系统架构的设计、配置、维护等工作。

今天就让我偷懒一次吧，实在不想插图了，希望大家能看得进去。

架构思维要从多方面考虑整体架构的设计，接下来的架构思维会涉及业务，各位看官需要自行对接业务来分析看待架构思维。

首先给出一个场景

一：业务语言确定为java

二：采用分布式业务集群

三：业务需要大量调度与查数据库

四：业务量适中

这几点是我企业中遇到的一个场景，同样也是大多数中小企业的现实场景。

一、为什么使用Java语言

java作为中大型企业的开发语言，他的安全性与规范性不言而喻，通过java语言实现的B/S架构的设计是大多开发者的选择，同样作为稳定选择，java与php之间的较量一直没有停过。

分层思想是是设计计算机系统过程中非常重要的思想。比如操作系统常见的硬件层、驱动层、应用层之间的关系。分层可以更好地实现高内聚、低耦合的效果。我们都知道，Java语言有着完备的MVC框架，包括视图层、业务控制层和持久层，在Spring框架中，我们可以通过IOC和AOP降低编码过程中的高耦合，也就是说Java中的这些框架可以让开发者有更广阔的空间去设计科学合理的架构，也体现着Java多层架构的特点。相比Java而言，PHP留给开发者的空间并不多，但PHP近些年也在改进，迎合电子商务的需要，引入MVC设计模式，但成熟性和稳定性上与Java还是有着不小的差距。不得不提的是PHP可兼容MySQL开发，这使得在考虑成本因素的前提下，PHP变得小而精，收到了一些中小型网站的青睐。但是按照成熟度来讲，PHP还是远远比不上java。

二、为什么采用分布式业务集群部署

分布式业务集群最大的好处就是提供了灰度发布的可能性，提高了整体业务系统的可用性与可恢复性，一旦出现问题能在短时间内回滚到稳定版本。同时分布式业务集群部署还可以分担整体业务带来的压力，包括网络上的压力，服务器性能上的压力等等。

整体的业务前情提要就是这样，那么从业务角度考虑怎么设计业务架构？

业务架构的设计思维要围绕着高可用性来考虑问题。既然是分布式业务集群，那么其中的服务器调度是免不了的，而且核心就应该放在调度上。在这里使用dubbo+zookeeper的架构设计（相对稳定，因为是个存在比较久的技术）。

什么是dubbo+zookeeper？

如果大家有兴趣可以详细学习学习，这里给出详细介绍链接

简单介绍一下，业务集群注册到注册中心，调用者通过注册中心订阅业务集群的变换，当需要调度时通过注册中心确定哪台服务器的状态是最佳的，将调度任务下发到那台服务器中，完成整个业务任务。

由于zookeeper的架构设计时有同步，3台zookeeper做成的集群可以实时同步数据，意味着如果有一台宕机，业务正常工作不说，宕机的那台不管因为什么原因导致zookeeper崩溃，哪怕卸载重装也不怕数据的丢失，充分保护了数据的可用性。

同时由于业务需要大量调度与查数据库，为避免大量查询语句影响数据库性能，引入redis进行数据缓存来减轻数据库的压力。

这是整体业务的架构思维，那么下面重点来讲一下围绕业务架构思维展开的安全架构思维。

首先明确一点，安全是离不开业务的，任何安全点的设计都应该充分考虑业务。

由于业务都是使用代码实现的，代码审计是必须的安全点，那么在安全架构设计思维初期，首先就要考虑代码审计。相关代码审计工具如果有经费建议使用厂商的，如果预算不充足给大家推荐cobra，具体使用详见

整体考虑代码量与审计服务器性能，建议采用集群方式进行代码审计。

同时业务的http特性还需要我们构建WAF，同样的如果有经费建议使用厂商的，如果预算不足我的其他文章中有写到很多关于自建WAF的文章，欢迎翻阅。

考虑到了服务器集群的统一管理，推荐使用堡垒机作为统一管理入口，同样的如果有经费建议使用厂商的，这里推荐齐治，如果预算不足建议使用开源堡垒机jumpserver。

使用详见：http://www.jumpserver.org

同样还有基线与漏洞扫描的设计，这块在后期我会详细讲解如何使用开源代码搭建自己的checkserver.

在保证了外部的相对安全后，要考虑内部的相对安全，加密传输无疑是比较大众和方便的一种手段。同样内部安全永远离不开运维监控的支持，只用做好协同，才能保证相对稳定与安全的服务器环境，而安全、稳定、高效、灵活，才是业务架构的根本所在。

*本文原创作者：煜阳yuyang，本文属于FreeBuf原创奖励计划，未经许可禁止转载