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

简介: 回到索引 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
本文版权归作者和博客园共有,欢迎转载,但未经作者同意必须保留此段声明,且在文章页面明显位置给出原文连接,否则保留追究法律责任的权利。
相关文章
|
3天前
|
API 持续交付 开发者
构建高效微服务架构:后端开发的新视角
【5月更文挑战第8天】 随着现代软件开发的演变,微服务架构已经成为了企业追求敏捷、可扩展和灵活部署的重要解决方案。本文将深入探讨如何构建一个高效的微服务架构,包括关键的设计原则、技术栈选择以及持续集成与部署的最佳实践。我们还将讨论微服务带来的挑战,如数据一致性、服务发现和网络延迟,并提出相应的解决策略。通过本文,后端开发者将获得构建和维护微服务系统所需的深度知识,并了解如何在不断变化的技术环境中保持系统的健壮性和可维护性。
35 8
|
1天前
|
存储 监控 API
构建高效微服务架构:后端开发的现代实践
【5月更文挑战第9天】 在本文中,我们将深入探讨如何在后端开发中构建一个高效的微服务架构。通过分析不同的设计模式和最佳实践,我们将展示如何提升系统的可扩展性、弹性和维护性。我们还将讨论微服务架构在处理复杂业务逻辑和高并发场景下的优势。最后,我们将分享一些实用的工具和技术,以帮助开发者实现这一目标。
|
2天前
|
Kubernetes 持续交付 开发者
构建高效微服务架构:后端开发的新趋势
【5月更文挑战第8天】 随着现代软件开发的不断演进,微服务架构已成为众多企业解决复杂系统问题的首选方案。本文深入探讨了微服务架构的核心概念、设计原则以及实施策略,旨在为后端开发者提供一种清晰、高效的技术路径。通过分析微服务的优势与挑战,结合具体的应用实例,文章将展示如何通过容器化、服务网格和持续集成/持续部署(CI/CD)等先进技术手段,实现后端服务的高可用性、可扩展性和敏捷性。
|
2天前
|
消息中间件 监控 Java
构建高效微服务架构:后端开发的新趋势
【5月更文挑战第8天】随着现代软件开发的复杂性日益增加,传统的单体应用架构逐渐难以满足快速迭代和灵活部署的需求。微服务架构作为一种新的解决方案,以其模块化、独立性强和易于扩展的特点,正在成为后端开发领域的重要趋势。本文将深入探讨如何构建一个高效的微服务架构,并分析其对后端开发实践的影响。
|
3天前
|
敏捷开发 持续交付 API
构建高效微服务架构:后端开发的现代实践
【5月更文挑战第8天】 在数字化转型的浪潮中,微服务架构已成为企业追求敏捷开发、持续交付和系统弹性的关键解决方案。本文将深入探讨微服务的核心概念,包括其设计原则、优缺点以及如何在后端开发中实现高效的微服务架构。我们将通过实际案例分析,展示微服务如何帮助企业快速适应市场变化,同时保持系统的可维护性和扩展性。
|
4天前
|
设计模式 Kubernetes 数据库
构建高效可靠的微服务架构:后端开发的新范式
【5月更文挑战第7天】在现代软件开发的浪潮中,微服务架构已经成为一种流行的设计模式。它通过将应用程序分解为一组小的、独立的服务来提高系统的可维护性和扩展性。本文深入探讨了微服务架构的核心概念、优势以及如何利用最新的后端技术构建一个高效且可靠的微服务体系。我们将讨论关键的设计原则,包括服务的独立性、通信机制、数据一致性和容错性,并展示如何在云环境中部署和管理这些服务。
17 3
|
4天前
|
缓存 监控 数据库
构建高性能微服务架构:后端开发的终极指南
【5月更文挑战第6天】 在现代软件开发的浪潮中,微服务架构以其灵活性、可扩展性和容错性引领着技术潮流。本文深入探索了构建高性能微服务架构的关键要素,从服务划分原则到通信机制,再到持续集成和部署策略。我们将透过实战案例,揭示如何优化数据库设计、缓存策略及服务监控,以确保系统的稳定性和高效运行。文中不仅分享了最佳实践,还讨论了常见的陷阱与解决之道,为后端开发者提供了一条清晰、可行的技术路径。
|
5天前
|
监控 负载均衡 持续交付
构建高效微服务架构:后端开发的新趋势
【5月更文挑战第5天】在数字化转型的浪潮中,微服务架构以其灵活性、可扩展性和容错性成为企业追求的技术典范。本文深入探讨了微服务的核心组件、设计原则和实施策略,旨在为后端开发者提供构建和维护高效微服务系统的实用指南。通过分析微服务的最佳实践和常见陷阱,我们揭示了如何优化系统性能、保证服务的高可用性以及如何处理分布式系统中的复杂性。
|
6天前
|
缓存 NoSQL Java
构建高性能微服务架构:Java后端的实践之路
【5月更文挑战第5天】在当今快速迭代和高并发需求的软件开发领域,微服务架构因其灵活性、可扩展性而受到青睐。本文将深入探讨如何在Java后端环境中构建一个高性能的微服务系统,涵盖关键的设计原则、常用的框架选择以及性能优化技巧。我们将重点讨论如何通过合理的服务划分、高效的数据存储策略、智能的缓存机制以及有效的负载均衡技术来提升整体系统的响应速度和处理能力。
|
6天前
|
负载均衡 Java 数据库
构建高效微服务架构:后端开发的新趋势
【5月更文挑战第5天】在现代软件开发中,微服务架构已经成为一种流行的设计模式。它通过将大型应用程序分解为一组小型、松散耦合的服务来提高可维护性、可扩展性和敏捷性。本文将探讨如何构建高效的微服务架构,包括选择合适的技术栈、设计良好的服务接口、确保数据一致性以及实现高可用性和负载均衡。