3：设计理念

　　每个架构师都会有一些自已原设计理念和原则。我的基本思路是：架构要作到至少1年的预见性(半年不叫预见性，因为方案实施要半年)。设计的目标是尽量让系统可以水平扩展，并利于。当然，有些业务处在生存的边缘，可能架构方案只有几个月的生命力。但一些成本不高收益稳定的架构理念，不管什么时候都是值得优先考虑的。以下是架构设计的一些常用手段。

　　1>：异步换同步：系统中的很多调用是可以异步化的，包括WEB界面上的AJAX异步，还有服务端的消息型异步;AJAX调用的应用要注意把这种类型的应用集中到一个隔离的服务系统中，以方便在必要的时候进行服务降级。

　　AJAX调用一般都是界面上非同步非强依赖的功能点;服务端异步的系统可以让服务端的请求RT变短，提升服务器QPS，同时减少应用强依赖。

　　一个小型系统(峰值万级消息per second)的服务端异步消息可以借助RMDB的表实现，当网站规模变大时(峰值百万级消息每秒)，消息系统需要有一个中间件，负责消息持久化及数据CRUD管理;再大点的时候，消息中间件的分布式与可用性会有更高要求，需要综合使用多种架构设计理念;

　　同步换异步对软件工程上的好处是，可以把一个子系统的不同模块分别由不同的人开发维护，调试期间，两个模块也不会有很强的依赖。提高开发并发性。

　　2>: 集中变分布：

　　一个网站小的时候，很多业务都会在一两个应用系统中实现。比如一个电子商务网站，从登录，到首页，到搜索，到产品DETAIL，到购物车，下单支付，风控，订单管理，用户中心到售后用户纠纷流程。网站小的时候，这种一体化的业务架构模式在网站规模小的时候，无论是研发团队规模还是硬件成本都是比较低的。这个时期的扩展性一般只需要作到LB后面挂一片集群。服务器资源利用率这时候也是比较高的。

　　随着业务规模扩大，需要把系统独立分拆出来，基本原则是：不同维护策略和服务等级的页面和服务 不要放在一个应用容器中，最好不要放在一个虚拟机或物理机上。发生过很多次紧急事件。因为大流量页面上带着一个小的AJAX请求，把提供AJAX服务的WEB应用压死。而这种AJAX应用平时又是比较容易在容量评估的时候被忽略的。也比较难以管理AJAX，因为一个前端开发工程师很可能因为一次小的运营活动加上一个调用。服务器端不同服务类型的功能也需要分拆到不同服务中，服务的聚合一定要有一定的原则，并不断的调整治理聚合服务内容。如果把一个文件生成类的业务功能(比如用户批量导入导单)和一个下单的服务放在一起，很容易让下单这类核心主干逻辑功能受批量导出功能影响，当架构师需要作服务降级时，不得不侵入代码层作服务功能的隔离。

　　架构上的基础设施也需要有隔离策略。比如一个功能先后需要完成读数据，再生成文件，再发消息，再写数据库，写CACHE，再把数据同步到另一个机房。这一串逻辑中，除了异步化策略之外，还需要考虑一些基础职能的隔离，比如把生成文件的功能封装成一个服务，文件存储也需要从集中式变成分布式。T级可以考虑NAS类的集中式存储方案，P级和Z级的文件容量一般是需要考虑分布式文件系统方案，开源的也比较多。数据库与从集中式变分布式是现在流行的方案，之前我们小网站的时候常用MASTER SLAVE，然后再大点搞双MASTER写，多SLAVE读;再大点流量或者应用系统过多时，数据库的连接数也会受到考验，这时候分布式的分库分表方案是必须的。当然对架构师来讲，如果能用上一种云方案，不需要业务架构师考虑分库分表方案，那会更有幸福感。同步系统也需要考虑集中变分布的策略，两个机房或同一机房两个系统进行数据镜像同步，需要考虑多通道，分表，分字段，分库进行同步，有时候还需加入一些商业逻辑作为同步数据的判断。非镜像同步的时候，同步系统还需要考虑业务逻辑之间的事务特性。