横向扩展能力
横向扩展是相对于纵向扩展而言的，纵向扩展即通过增加硬件规模来增加系统容量，横向扩展是通过复制“服务”(业务服务、数据服务等)来增加系统容量(可以使用价格低廉的硬件资源或者基于云)。
一个显而易见的好处就是可以节省高端服务器的开支，当然你也可以认为这项支出没什么大不了的。毕竟是钱可以解决的问题，但是接下来的好处就不是用钱能解决的了。
横向扩展的另一个结果就是系统必须要拆分成一个个小的、相互独立的子系统，通过这种方式也可实现拆分和解耦。这样虽然会带来更多的跨系统交互，但是相对于所带来的好处来看，这点代价是完全值得的，且规模越大优势越明显。
那么怎么降低或解决跨系统交互带来的问题呢?——规范。接口定义规范、接口使用规范、接口更改规范、接口安全规范等等，通过定义上述规范病严格遵守，那么跨系统调用的问题就会在最大的程度上避免，仍然是那句话“规模越大优势越明显”，如果有疑问可以先试试再讨论。
降低了系统的维护难度。维护一个小系统的难度远远小于维护一个复杂且庞大系统的难度(如果你维护过这样高难度的系统，那么你的感受会更深一些)，针对小系统的调整、bug修改甚至是重构都会变的更加容易，只要保证对外接口的稳定性即可。
最后一个需要注意的问题就是避免单点故障，任何一个服务都不能只部署在一个点，同时要处理好同一服务多点部署的负载均衡及故障屏蔽(更多依赖于服务化整体解决方案)。
正确使用缓存
缓存的涉及范围广、使用复杂度高，正确的使用缓存能在很大程度上提高系统的响应速度、减少用户等待时间，同时也能缓解应用服务器压力及数据库服务器压力。缓存可粗略分为页面缓存和数据缓存两大类。
页面缓存是位于web服务器之前的缓存服务器，通过缓存和响应之前生成的动态请求，从而降低最终落在web服务器上的请求数量。
CDN的出现及大规模使用，将静态页面(也包括动态页面的js、css等内容)部署在CDN服务器上，有助于分流高峰期站点流量，同时CDN也可以将请求发送到最适合的节点以带来响应速度的提升。CDN通过定期检查源服务器来更新内容，这样极大的降低了源服务器的压力，同时也降低了成本。
数据缓存即针对纯数据的缓存，可以是数据库(表)数据的拷贝，也可以是在此基础上加工并组装的具有某种业务含义的数据。数据缓存通畅也被称为对象缓存。
在使用数据缓存时，要特别注意数据有效期，当数据发生变化时要及时更新缓存，否则就会读到脏数据。由此可见，控制好缓存数据入口非常重要，这也说明(跨系统)接口调用的重要性，每种业务的缓存由该业务代码进行控制，其余系统仅通过接口调用方式使用其数据，避免因入口分散导致缓存数据更新不及时而引起的脏读。
坚持容错
容错，对于构建高可用系统是至关重要的一个环节。没有容错的系统是不完整的系统、不健康的系统。对于开发人员来说，容错至少存在于两个层次：系统框架层、业务应用层(当然也可细分成公共业务、具体业务等)。前者处理共性问题，如RPC框架的超时、异常返回等情况;后者是具体业务的容错，比如收到不合法数据或者数据中不包含关键项的内容、由于信息不同步导致的接口变化而引起的返回数据格式活内容变化等。面对林林总总的不一致、错误、甚至异常，程序是否能做到容错呢?全量容错比部分好，部分容错比没有好。
开关，一种被广泛应用的显式容错方式，通过开关控制功能的状态，根据开关状态进行不同的处理，这种容错易于设计和实现，同时也容易被理解。对于开关的设计要小心、对于开关的使用控制要严格、对开关的兼容要完善、对开关的监控要完整，小心使用开关、在何时的地方使用开关能给系统带来莫大的好处。，
容错的另一个角度是对业务隔离，就像泳道一样，不同业务之间不能产生影响。当然这是一种理想的状况，不能做到百分之百的互相不影响，但是可以通过技术手段实现被以来的服务如果出问题了，依赖的服务可以兼容这种错误，给用户一个友好的提示或者在业务允许的条件先保存业务的中间状态，待被依赖服务重新具备服务能力后通知用户继续之前未完成的业务。
异步通信
所谓异步通信，通常指通过对消息中间件的使用将同步调用转为异步调用，异步调用相比同步调用的好处是无需等待，只需要确认将数据发送到消息中间件即可，数据的处理由另外的程序进行，也就是将数据的产生与处理隔离开来，互相不知道对方的具体位置。
在实际使用中，并不是所有场景都适合使用异步通信，只有那些对于实时性要求不高的场景适合使用，这点一定要注意。任何技术方案、技术组件都不是万能的。
由于不同的消息中间件具有不同的特点，在选择时也需要留意，甚至可以在不同的场景使用不同的消息中间件，这完全取决于具体业务场景的需求，比如对于消息中间价吞吐量和持久化数据量要求高、对消息中间件并发能力要求高等等。
对于消息中间件一样要避免单点故障，因此其可扩展能力就显得尤为重要。当部署一个消息中间件集群时，我们至少要考虑到这个集群的负载均衡怎么处理、业务数据是否持久化、每个节点的数据是全量还是部分、节点间是否需要数据同步以及怎么同步、当其中一个或几个节点挂掉后集群怎么保证持续提供服务能力。。。
当解决了上述问题后，我们就会面临另外一个问题，一个消息中间件的集群有多大容量或者说某一类或几类业务需要什么规模的消息中间价集群?这就需要我们对业务规模、消息中间件特性有综合的评估，合理的规划消息中间件集群及规模，做到心中有数。
联系客服
