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

简介: 回到索引 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
本文版权归作者和博客园共有,欢迎转载,但未经作者同意必须保留此段声明,且在文章页面明显位置给出原文连接,否则保留追究法律责任的权利。
相关文章
|
17天前
|
JavaScript Java Go
探索Go语言在微服务架构中的优势
在微服务架构的浪潮中,Go语言以其简洁、高效和并发处理能力脱颖而出。本文将深入探讨Go语言在构建微服务时的性能优势,包括其在内存管理、网络编程、并发模型以及工具链支持方面的特点。通过对比其他流行语言,我们将揭示Go语言如何成为微服务架构中的一股清流。
111 53
|
21天前
|
API 持续交付 开发者
后端开发中的微服务架构实践与挑战
在数字化时代,后端服务的构建和管理变得日益复杂。本文将深入探讨微服务架构在后端开发中的应用,分析其在提高系统可扩展性、灵活性和可维护性方面的优势,同时讨论实施微服务时面临的挑战,如服务拆分、数据一致性和部署复杂性等。通过实际案例分析,本文旨在为开发者提供微服务架构的实用见解和解决策略。
|
5天前
|
消息中间件 监控 持续交付
后端开发中的微服务架构设计与实践####
在当今快速发展的软件开发领域,微服务架构已成为构建高效、可扩展和易于维护应用的关键策略。本文将深入探讨微服务架构的核心概念、设计原则与实战技巧,通过实例解析如何在后端开发中有效实施微服务,以应对复杂业务需求和技术挑战。我们将从微服务的拆分策略、通信机制、数据管理到持续集成/持续部署(CI/CD)流程,全面剖析其背后的技术细节与最佳实践,为读者提供一份详尽的微服务架构设计与实践指南。 ####
|
3天前
|
缓存 负载均衡 API
后端开发中的微服务架构实践与挑战####
在数字化转型的浪潮中,微服务架构凭借其高度的可扩展性、灵活性及易于维护的特点,成为众多企业后端开发的首选架构模式。本文将深入探讨微服务架构的核心理念,通过具体案例分析其在实际应用中的实践策略与面临的挑战,为读者提供一份详尽的微服务架构实施指南。 ####
|
13天前
|
监控 API 微服务
后端技术演进:从单体架构到微服务的转变
随着互联网应用的快速增长和用户需求的不断演化,传统单体架构已难以满足现代软件开发的需求。本文深入探讨了后端技术在面对复杂系统挑战时的演进路径,重点分析了从单体架构向微服务架构转变的过程、原因及优势。通过对比分析,揭示了微服务架构如何提高系统的可扩展性、灵活性和维护效率,同时指出了实施微服务时面临的挑战和最佳实践。
35 7
|
14天前
|
监控 Go API
Go语言在微服务架构中的应用实践
在微服务架构的浪潮中,Go语言以其简洁、高效和并发处理能力脱颖而出,成为构建微服务的理想选择。本文将探讨Go语言在微服务架构中的应用实践,包括Go语言的特性如何适应微服务架构的需求,以及在实际开发中如何利用Go语言的特性来提高服务的性能和可维护性。我们将通过一个具体的案例分析,展示Go语言在微服务开发中的优势,并讨论在实际应用中可能遇到的挑战和解决方案。
|
15天前
|
Go 数据处理 API
Go语言在微服务架构中的应用与优势
本文摘要采用问答形式,以期提供更直接的信息获取方式。 Q1: 为什么选择Go语言进行微服务开发? A1: Go语言的并发模型、简洁的语法和高效的编译速度使其成为微服务架构的理想选择。 Q2: Go语言在微服务架构中有哪些优势? A2: 主要优势包括高性能、高并发处理能力、简洁的代码和强大的标准库。 Q3: 文章将如何展示Go语言在微服务中的应用? A3: 通过对比其他语言和展示Go语言在实际项目中的应用案例,来说明其在微服务架构中的优势。
|
15天前
|
监控 API 持续交付
后端开发中的微服务架构实践与挑战####
本文深入探讨了微服务架构在后端开发中的应用,分析了其优势、面临的挑战以及最佳实践策略。不同于传统的单体应用,微服务通过细粒度的服务划分促进了系统的可维护性、可扩展性和敏捷性。文章首先概述了微服务的核心概念及其与传统架构的区别,随后详细阐述了构建微服务时需考虑的关键技术要素,如服务发现、API网关、容器化部署及持续集成/持续部署(CI/CD)流程。此外,还讨论了微服务实施过程中常见的问题,如服务间通信复杂度增加、数据一致性保障等,并提供了相应的解决方案和优化建议。总之,本文旨在为开发者提供一份关于如何在现代后端系统中有效采用和优化微服务架构的实用指南。 ####
|
17天前
|
消息中间件 设计模式 运维
后端开发中的微服务架构实践与挑战####
本文深入探讨了微服务架构在现代后端开发中的应用,通过实际案例分析,揭示了其在提升系统灵活性、可扩展性及促进技术创新方面的显著优势。同时,文章也未回避微服务实施过程中面临的挑战,如服务间通信复杂性、数据一致性保障及部署运维难度增加等问题,并基于实践经验提出了一系列应对策略,为开发者在构建高效、稳定的微服务平台时提供有价值的参考。 ####
|
18天前
|
消息中间件 监控 数据管理
后端开发中的微服务架构实践与挑战####
【10月更文挑战第29天】 在当今快速发展的软件开发领域,微服务架构已成为构建高效、可扩展和易于维护应用程序的首选方案。本文探讨了微服务架构的核心概念、实施策略以及面临的主要挑战,旨在为开发者提供一份实用的指南,帮助他们在项目中成功应用微服务架构。通过具体案例分析,我们将深入了解如何克服服务划分、数据管理、通信机制等关键问题,以实现系统的高可用性和高性能。 --- ###
38 2
下一篇
无影云桌面