我的架构经验系列文章 - 后端架构 - 系统层面

系统层面:

高可用性

所谓高可用性也就是通过避免单独故障加上快速故障转移实现一旦某台物理服务器出现故障能实现故障快速恢复。一般来说,可以采用两种方式,如果可以做业务可以做负载均衡则通过负载均衡实现集群,然后针对每一台服务器进行监控,一旦发生故障则从集群中移除;如果业务只能有单点入口那么可以通过实现Standby机加上虚拟IP机制,实现Active机在出现故障之后虚拟IP转移到Standby的快速故障转移。一般可以使用KeepAlived或HeartBeat实现高可用(当然,硬件手段实现也可以,这里不展开讨论)。

高伸缩性

所谓高伸缩性也就是横向伸缩性,通过扩展机器数量而不是增加机器配置来实现系统处理能力的扩容。负载均衡就是典型的高伸缩性的架构,此外还可以把业务进行拆分由不同的服务器实现不同的业务也是一种伸缩性的方案。一般来说对于没有状态的Web服务比较容易实现负载均衡,而数据库层面,特别是数据库的写操作比较难以实现横向伸缩。一般可以使用LVS或HAPROXY实现负载均衡(当然,硬件手段实现也可以,这里不展开讨论)。

反向代理

对于网站前端一般会使用反向代理来为服务器实现缓存和负载均衡的工作。这个缓存不同数据缓存,是把用于输出的HTML或HTML片段进行内存或磁盘的缓存,以减少Web服务器的压力。一般可以使用SQUID或VARNISH实现反向代理。

分享一个最好用的UI前端框架!

CDN

为了进一步增加网站页面的访问速度,可以为静态资源、图片甚至动态资源进行CDN。CDN供应商在全国的骨干节点都设有服务器,可以让全国各地的用户都可以高速访问到这些静态资源,当然静态资源第一次访问是需要通过我们的静态资源服务器的,之后就会在CDN的服务器上进行一段时间的缓存。CDN不但可以加速客户端的访问速度还可以减少服务器的压力。如果网站的页面又实现了CDN,又通过反向代理缓存,那么更新起来就会比较麻烦,因为这样的话可能会在客户端、CDN服务端以及反向代理端都有缓存,此时需要通过一些工具来判断到底是哪个环节有缓存。分享一个最好用的UI前端框架!

操作系统参数

在拿到服务器之后,操作系统的配置可能是默认的,此时应该检查操作系统是否修改了诸如TCP连接数量、最大文件句柄数量等系统参数,避免因为操作系统的限制不能发挥程序的最佳性能。

服务器优化

不管是诸如Nginx或Apache的Web服务器还是诸如Tomcat或JBoss的Java服务器,都有一些参数设置,需要根据服务器的配置结合网上的一些最佳实践进行一些参数的修改,往往默认配置是不适合配置比较高的服务器的。比如,Java是一种基于垃圾回收的语言,过大的堆可能会导致垃圾回收的时间过长,因此往往会针对大内存的服务器配置多个32bit的JVM而不是统一使用一个64bit的JVM并分配16GB以上的内存给它。我们需要明白服务器中相关参数的意义,有理有据进行参数设置。

时间: 2024-11-05 15:56:38

我的架构经验系列文章 - 后端架构 - 系统层面的相关文章

我的架构经验系列文章 - 后端架构 - 框架层面

框架层面: SOA 在这一篇中会逐个介绍一下自己对这些XXX的理解,其实每一个理念都不是莫名其妙产生的而是有产生背景的,这些时髦的名词不是用来炫耀的,而是真正要理解它们是干什么的,并且框架千万不能乱用理念也千万不能乱用,并不是把所有的这些都用上你的系统才是一个牛逼的系统,一定要适合才是最好的,并且要保持简单可靠的原则.所谓SOA,字面上来说是面向服务的架构.有的人不说SOA其实他已经SOA了,有的人大谈SOA但其实只是在用Web服务,SOA可大可小.你可以认为服务调用就是SOA了,也可以认为服务

我的架构经验系列文章 - 后端架构 - 架构层面

架构层面: 日志集中 所谓日志集中就是把程序的所有日志和异常信息的记录都汇总到一起,在只有一台服务器的时候我们记录本地文件问题也不是最大,但是在负载均衡环境下再记录本地日志的话就出现问题了.在想查看网站日志的时候到哪台机器去查都不知道,难道有100台机器就100台机器逐一远程连上去看?因此,把这些数据汇总在一起保存对于大型网站系统来说是很必要的,这样我们就可以直接进行查看.搜索,也很明确可以知道是哪台机器的业务出了问题.至于这种日志数据是写到RDBMS还是NOSQL甚至是搜索引擎这就看需要了,总

我的架构经验系列文章 - 后端架构 - 设计层面

设计层面: 分层架构 分层架构是项目设计中很重要的一点,从根本的目的上来说就是为了职责的分离.最经典的三层架构,到四层五层六层,甚至有人开玩笑说十八层的分层,根据项目的需要可以分不同的层.这里说的层其实是逻辑层,从物理层的角度来说也有三层.四层五层的分层架构.之所以三层架构这么流行是因为它的分层把大的关注点进行了分离,层数恰到好处,表现层.业务逻辑层和数据访问层,分别处理面向用户呈现的.面向逻辑处理的和面向数据库存取数据的三大关注点.UI前端框架最新力作!有奖试读! 在分层架构中除了分层之外还需

我的架构经验系列文章 - 后端架构 - 性能层面

性能层面: 性能分析 我觉得性能分析的话要注意几个要点: 不要去猜:对于自己写的代码你是否知道你的代码要执行多久,是不是还在用时间相减来测试代码执行时间?现在有很多自动化的工具可以在程序运行的时候,测试代码中每一句语句的执行时间,可以有效分析出代码的性能瓶颈.对于比较重要的业务逻辑建议采用类似的工具来进行性能分析,有的时候性能慢的代码不一定是自己写的还可能是框架内提供的,如果没有一个丰富的编码经验是不太可能知道这些点的,但是通过这样的分析工具你就能知道这个地方会慢,虽然框架的代码我们不能改,但是

我的架构经验系列文章 - 后端架构 - 语言层面

语言层面: 运行时元数据获取 所谓运行时元数据获取也就是在程序 运行的时候通过代码动态 获得类型.方法.属性的信息,然后可以动态获得属性的值,执行方法等等,在有的语言中称为反射.反射不一定是高效的,但是在写框架程序的时候反射是一种很有用的技术 ,并且反射的性能开销往往是可以通过诸如缓存等手段来最小化的.比如在ORM中,根据实体类的信息动态获得所有的属性,然后取得其值,生成要到数据库 中执行的SQL语句.理解反射熟练掌握反射的使用以及性能优化是编写框架类代码很重要的一点. 错误处理 任何后端语言都

我的架构经验系列文章 - 后端架构 - 安全层面

安全层面: SQL注入 SQL注入是一个古老的安全问题,现在任何程序都不应该再出现这样的问题了,其原理非常简单,在过去大多数程序都是直肠子通数据库的,因此如果拼接SQL并且在参数上没有做好过滤或者没有使用参数形式来生成SQL语句的话可能会导致用户在页面上输入的恶意代码直接在数据库中执行.SQL注入的危害点在于整个网站有1000个数据点,如果其中有1个点有漏洞那么整站的数据其实都有危险了,很多开发会注重资金相关的模块但是忽略新闻相关的模块,如果都是使用一套数据库的话那么一个不重要模块的漏洞就会影响

我的架构经验系列文章 - 前端架构

框架层面:近几年前端发展很快,前端之所以叫前端因为前端是已经可以独立成为一种职业了,js也不再是十年前的玩具了,以前富客户端RIA的应用可能会用flash/flex或是silverlight,现在可以使用js来完成大部分的功能,因此js作为一门前端的支撑语言也不仅仅是进行的简单的编码,越来越多框架性的东西出现了.越来越多的开发模式转变为后端只是吐json的数据源,而前端做所有UI的事情. MVC MVC实现职责分离是很好的,大多数网站在后端都会引入MVC框架,对于一个前端负责所有呈现和前端业务逻

mysql 架构篇系列 2 复制架构一主一从搭建(异步复制)

一. 环境准备 1.1 主库环境(172.168.18.201) 环境 说明 查看脚本 操作系统版本 CentOS Linux release 7.4.1708 (Core) cat /etc/redhat-release 操作系统用户名和密码 root  js*2015 IP地址 172.168.18.201 ip addr 网关Gateway 172.168.18.1 cat /etc/sysconfig/network-scripts DNS 172.168.16.11 mysql 版本

NET架构设计、框架设计系列文章总结

NET架构设计.框架设计系列文章总结 从事.NET开发到现在已经有七个年头了.慢慢的可能会很少写.NET文章了.不知不觉竟然走了这么多年,热爱.NET热爱c#.突然想对这一路的经历进行一个总结. 是时候开始下一阶段的旅途,希望这些文章可以在发挥点价值作用. 架构设计: ElasticSearch大数据分布式弹性搜索引擎使用 (推荐) DDD实施经验分享-价值导向.从上往下进行(圈内第一个吃螃蟹DDD实施方案)(推荐) 软件工程-思考项目开发那些事(一)(推荐) SOA架构设计经验分享-架构.职责