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

简介: 回到索引 http://www.cnblogs.com/lovecindywang/archive/2012/12/23/2829828.html   语言层面:   运行时元数据获取 所谓运行时元数据获取也就是在程序运行的时候通过代码动态获得类型、方法、属性的信息,然后可以动态获得属性的值,执行方法等等,在有的语言中称为反射。

回到索引 http://www.cnblogs.com/lovecindywang/archive/2012/12/23/2829828.html

 

语言层面:

 

  • 运行时元数据获取

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

 

  • 错误处理

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

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

 

  • 垃圾回收

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

 

  • 多线程

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

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

 

  • 代码生成

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

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

 

 

作者: lovecindywang
本文版权归作者和博客园共有,欢迎转载,但未经作者同意必须保留此段声明,且在文章页面明显位置给出原文连接,否则保留追究法律责任的权利。
相关文章
|
29天前
|
弹性计算 API 持续交付
后端服务架构的微服务化转型
本文旨在探讨后端服务从单体架构向微服务架构转型的过程,分析微服务架构的优势和面临的挑战。文章首先介绍单体架构的局限性,然后详细阐述微服务架构的核心概念及其在现代软件开发中的应用。通过对比两种架构,指出微服务化转型的必要性和实施策略。最后,讨论了微服务架构实施过程中可能遇到的问题及解决方案。
|
16天前
|
机器学习/深度学习 前端开发 算法
婚恋交友系统平台 相亲交友平台系统 婚恋交友系统APP 婚恋系统源码 婚恋交友平台开发流程 婚恋交友系统架构设计 婚恋交友系统前端/后端开发 婚恋交友系统匹配推荐算法优化
婚恋交友系统平台通过线上互动帮助单身男女找到合适伴侣,提供用户注册、个人资料填写、匹配推荐、实时聊天、社区互动等功能。开发流程包括需求分析、技术选型、系统架构设计、功能实现、测试优化和上线运维。匹配推荐算法优化是核心,通过用户行为数据分析和机器学习提高匹配准确性。
52 3
|
2月前
|
弹性计算 持续交付 API
构建高效后端服务:微服务架构的深度解析与实践
在当今快速发展的软件行业中,构建高效、可扩展且易于维护的后端服务是每个技术团队的追求。本文将深入探讨微服务架构的核心概念、设计原则及其在实际项目中的应用,通过具体案例分析,展示如何利用微服务架构解决传统单体应用面临的挑战,提升系统的灵活性和响应速度。我们将从微服务的拆分策略、通信机制、服务发现、配置管理、以及持续集成/持续部署(CI/CD)等方面进行全面剖析,旨在为读者提供一套实用的微服务实施指南。
|
30天前
|
运维 监控 Java
后端开发中的微服务架构实践与挑战####
在数字化转型加速的今天,微服务架构凭借其高度的灵活性、可扩展性和可维护性,成为众多企业后端系统构建的首选方案。本文深入探讨了微服务架构的核心概念、实施步骤、关键技术考量以及面临的主要挑战,旨在为开发者提供一份实用的实践指南。通过案例分析,揭示微服务在实际项目中的应用效果,并针对常见问题提出解决策略,帮助读者更好地理解和应对微服务架构带来的复杂性与机遇。 ####
|
29天前
|
消息中间件 运维 安全
后端开发中的微服务架构实践与挑战####
在数字化转型的浪潮中,微服务架构凭借其高度的灵活性和可扩展性,成为众多企业重构后端系统的首选方案。本文将深入探讨微服务的核心概念、设计原则、关键技术选型及在实际项目实施过程中面临的挑战与解决方案,旨在为开发者提供一套实用的微服务架构落地指南。我们将从理论框架出发,逐步深入至技术细节,最终通过案例分析,揭示如何在复杂业务场景下有效应用微服务,提升系统的整体性能与稳定性。 ####
40 1
|
30天前
|
消息中间件 运维 API
后端开发中的微服务架构实践####
本文深入探讨了微服务架构在后端开发中的应用,从其定义、优势到实际案例分析,全面解析了如何有效实施微服务以提升系统的可维护性、扩展性和灵活性。不同于传统摘要的概述性质,本摘要旨在激发读者对微服务架构深度探索的兴趣,通过提出问题而非直接给出答案的方式,引导读者深入
45 1
|
1月前
|
负载均衡 监控 API
后端开发中的微服务架构实践与挑战
本文深入探讨了微服务架构在后端开发中的应用,分析了其优势和面临的挑战,并通过案例分析提出了相应的解决策略。微服务架构以其高度的可扩展性和灵活性,成为现代软件开发的重要趋势。然而,它同时也带来了服务间通信、数据一致性等问题。通过实际案例的剖析,本文旨在为开发者提供有效的微服务实施指导,以优化系统性能和用户体验。
|
1月前
|
弹性计算 Kubernetes API
构建高效后端服务:微服务架构的深度剖析与实践####
本文深入探讨了微服务架构的核心理念、设计原则及实现策略,旨在为开发者提供一套系统化的方法论,助力其构建灵活、可扩展且易于维护的后端服务体系。通过案例分析与实战经验分享,揭示了微服务在提升开发效率、优化资源利用及增强系统稳定性方面的关键作用。文章首先概述了微服务架构的基本概念,随后详细阐述了其在后端开发中的应用优势与面临的挑战,最后结合具体实例,展示了如何从零开始规划并实施一个基于微服务的后端项目。 ####
|
2月前
|
消息中间件 监控 API
后端开发中的微服务架构实践与挑战####
本文深入探讨了微服务架构在现代后端开发中的应用,分析了其优势、实施过程中的关键考虑因素及面临的挑战。不同于传统的单体应用,微服务通过拆分功能模块为独立服务,提升了系统的灵活性和可维护性。我们将从微服务的基本概念入手,逐步剖析其在真实场景下的应用案例,并讨论如何有效应对服务间通信、数据一致性等复杂问题,旨在为开发者提供一套实用的微服务落地指南。 ####
27 0
|
25天前
|
存储 缓存 负载均衡
后端开发中的性能优化策略
本文将探讨几种常见的后端性能优化策略,包括代码层面的优化、数据库查询优化、缓存机制的应用以及负载均衡的实现。通过这些方法,开发者可以显著提升系统的响应速度和处理能力,从而提供更好的用户体验。
51 4