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

语言层面:

  • 运行时元数据获取

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

  • 错误处理

任何后端语言都有其错误处理机制,.NET 和Java的异常处理机制也被更多的语言所吸纳,虽然每种语言的异常机制不一定都相同,但是也是大同小异。错误处理和异常处理的原则个人总结如下:

  • 不要把错误的结果吃掉,不要把捕获的异常吃掉。所谓吃掉也就是针对错误结果或异常不做任何的处理,这样就没有人知道这个异常的存在这是很危险的。其实所谓异常就是代码不能执行代码语句本身所隐含的含义,比如有一个方法从名字上看是创建文件的,那么不能创建文件的时候方法应该是要抛出异常的,因为它办不了它应该办的事情,作为类库的编写者应该要这么做,有的时候出了问题我们会很迷茫为什么会出问题,作为类库的使用者应该在这样的方法周围进行异常处理,并且记录这样的异常,那么我们就很容易通过异常信息来找到根源问题,而不是去猜。有的时候根本没办法通过猜来解决问题,因为语言的类库是和操作系统打交道的一首环节,只有类库才知道操作系统有什么问题,比如是因为权限原因不能创建文件还是因为磁盘损坏,如果把这个异常信息舍弃的话是很难知道根本原因的。UI前端框架最新力作!有奖试读!
  • 具体怎么进行错误处理不能一视同仁需要看情况而定的。并且一般不建议直接捕获最大的异常,能细化的尽量细化,捕获所有异常意味着不能进行处理。一般情况下可以记录日志,或是重新包装后抛出,或是很明确地进行错误处理。
  • 未处理的异常往往会随着调用栈往上升,升到最上层如果Web服务器发现异常还是未处理的话会导致各种颜色的错误页面。个人认为出现错误页面不一定是坏事情,很多人喜欢把所有的异常都吃掉不出现错误页,这不是解决问题的根本办法,根本办法是找到异常出现的原因,从代码角度解决它,而不是掩耳盗铃。当然,错误页是不应该让终端用户看到的,应该替换成友好的页面,在这个页面上可以什么都不写,也可以写一个异常ID,如果用户觉得这个操作是很要紧的话可以拿这个异常ID来和客服反馈,阐述其操作过程帮助我们解决问题,当然这个大前提是能把所有的异常都记录到数据库或方便查询的文本文件中。很多框架都具有统一收集未处理异常的入口点,在这里我们可以统一把未处理的异常汇总记录。
  • 垃圾回收

除了C/C++之外大多数脚本语言和具有虚拟机的编译型语言都是自动垃圾回收的。虽然通过垃圾回收机制不需要手动来处理对象的释放,但垃圾回收不是万能的,可能是会导致内存泄露问题的。当然,这里说的内存泄露和C/C++的内存泄露其实不太一样,一般而言垃圾回收通过向上回溯对象引用根来判断对象是否可以被回收,如果我们程序写的不当导致对象始终存在引用根的话可能就会导致对象不能得到释放产生不断的内存膨胀,虽然说对象是存在指针指向的,并不是没有任何指针指向的野对象,但是其实我们是遗忘这个对象的,因此也可以说是是有内存泄露。因此,即使有垃圾回收我们也要特别注意一下静态对象的使用,是不是一定要是静态的,是不是可以是弱引用的,尽量避免使用声明周期过长的根。 UI前端框架最新力作!有奖试读!

  • 多线程

大多数的编译型语言都支持用代码编写多线程,多线程是一个很有用的技术,可以用来让主线程、UI线程不因为其它操作停止响应,可以用来同时执行多个任务来提高任务执行的速度,充分利用多核CPU的处理能力,当然也可以把一个任务直接分割成多个任务并行执行,实现有多少CPU就可以执行多快。由于在编码的时候不能预测多线程的程序在执行时候的调度,所以我们在编码的时候就要特别小心多线程带来的问题:

  • 如果多线程同时访问一个资源,比如同时对一个数字进行累加,那么很可能不到达到我们的预期。
  • 类库所提供的类型不一定都是线程安全的,我们在使用的时候务必要阅读相关的资料确认是不是线程安全的,如果不是那么我们要通过诸如锁之类的手段来确保能够线程安全,否则很可能在调用类库的时候会出现异常或者说不能实现正确的代码。
  • 多线程的程序调试起来也是比较麻烦的,因为多个线程可能会穿插执行不同的代码,此时我们可以通过记录日志、挂起某些线程或是临时切换为单线程程序来增加代码的调试性。
  • 我们在编码的时候需要意识到什么是线程,一个线程所消耗的资源有多少,因为不要认为多线程可以提高效率,什么操作都用一堆线程来做,随便开启很多线程,这是得不偿失的,线程虽然比进程的代价小但是代价也不是这么小,因为每一个线程都有一个不小的线程栈,因此如果你发现你的程序开启了上千个线程的话,那么或许要想一下这样是否合理了。
  • 在开启多线程的时候千万要记得不要遗忘这个线程,不要让线程在哪里什么都不干空循环,对于后台任务类线程,可以在一个地方记录我们程序中开启的线程,对于其它可以结束的线程,要确保线程中的代码能正常结束。
  • 如果线程中的代码出现异常的话,大多数运行时或虚拟机会认为这是一个比较严重的问题,因为可能会导致整个系统中的状态不能保持一致,比如涉及到钱的系统这就是一个严重问题了,因此对于这种情况宁肯直接终止整个应用程序的进程也不要让这个问题没有人发现,错误的状态得到扩散,如果你觉得线程其实只是做一些无关重要状态的操作的话,务必确保线程不会出现未处理的异常。UI前端框架最新力作!有奖试读!
  • 代码生成

代码生成的作用很多,比如可以通过代码生成来减少我们代码的书写量,也可以通过代码生成实现AOP之类的切面操作。一般而言有两种代码生成的方式:

  • 动态生成:代码是在程序运行的时候动态生成的,生成的代码在动态编译后动态加载到运行环境中动态执行,这比较适合根据程序的逻辑动态生成一些代码来执行,比如动态生成代理类,代理类的接口如果是事先无法确定的,那么我们也不可能在编译前就生成代码。
  • 静态生成:一般是在编译前生成,然后直接进行编译的。比如自动根据XML中的相关数据定义生成CRUD的操作代码,既可以避免手写代码,又可以得到和手写代码相同的效率,因为这个代码其实还是死的还是固定的,并不是在运行时动态组织的,因此它的效率是最高的。
时间: 2024-08-01 17:10:41

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

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

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

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

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

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

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

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

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

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

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

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

安全层面: 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架构设计经验分享-架构.职责