架构师速成-架构目标之正确性

本系统架构模式：

  • 统一异常

    • 统一异常处理是保证程序正确性的第一步，这是第一个架构模式。具体如何实现，详见前面的文章。
  • 日志
    • 日志也是保证程序正确的一大手段，虽然是在错误出现后，日志才会记录。但是日志是快速确认问题，并分析出隐藏问题的重要手段。
    • 关键点
      • 日志文件按照级别进行区分，将错误和普通调试日志分开
      • 日志文件滚动方式，可以按天及按大小滚动，定时清理
      • 日志级别可以实时调整设置
      • 性能

支撑系统：

  • 测试系统

    • 自动化单元测试，保证基础模块的正确性
    • 自动化功能测试，保证每次代码更新的正确性
  • 监控系统
    • 监控异常日志，及时报警
  • 运维系统
    • 自动化发布，减少人为操作造成错误
    • 分批次发布，可以在线上小数据量测试，保证功能正确后，再全部升级
  • 对账系统
    • 对应金钱或库存相关的系统，需要有实时对账系统，校验每个订单是否符合预期，及时止损
时间： 2024-09-20 01:07:09

架构师速成-架构目标之正确性的相关文章

架构师速成-架构体系

经过这段时间的反思和整理,终于对架构有了一个较为明确的理解.架构是产品从无到有以及慢慢壮大过程中所需要的全部技术体系总称,架构过程: 配置.编码.测试.运维.监控分析.安全.运营等一系列技术体系的选型.取舍 技术选型基础上进行规划.设计.实现.迭代.制定相关规范 相关技术及规范运用到产品开发的整个过程中,并在产品迭代过程中对架构进行迭代优化 架构不止包含技术的框架,比如有人用了spring就觉得我已经是架构师了,其实架构并不是这么简单.我们以做一个新浪微博类似产品为例,现实应该是这样的: 产品初

架构师速成-架构的目标

架构的目标为了实现以下特性: 正确性 系统首先需要正确,运行稳定 可用性 软件系统对于用户的商业经营和管理来说极为重要,因此软件系统必须非常可靠,一般99.99%是一个比较基本的要求. 快速开发 互联网目前是一个快鱼吃慢鱼的时代,已经不是大鱼吃小鱼了.因为小鱼在一夜之间就长大了,把大鱼吃掉了.诺基亚就是明证,facebook就是明证. 良好体验 良好的体验对用户的吸引力是巨大的,某迅公司往往是抄一个产品,把用户体验做好,然后原产品就没有然后了. 伸缩性 用户激增的时候,网站可以伸缩来支持用户的增

架构师速成-架构目标之伸缩性\安全性

为满足伸缩性,所需的架构模式包含: 分布式,这个前面有单独的章节进行了讲解,分布式是互联网时代的主旋律. 负载均衡,前面已经有讲解. 服务拆分,按照业务进行系统服务的拆分并单独部署. 为满足伸缩性,需要的支撑系统: 运维系统: 自动扩容,缩容 监控系统 监控流量,确定何时伸缩 为满足安全性,所需的架构模式包含: 数据加密,密码的加密存储.关键数据的加密传输,才有https. 数据校验,数据传输时,同时传递明文和密文校验数据未被篡改.前端及后端进行数据的有效性校验,比如数字.日期等. 为满足安全性

架构师速成-架构目标之可用性

服务器等,从而共同完成工作任务.各种负载均衡的软硬件有很多,我们可以单独讲解一下. 配置中心,原来单一节点的配置,被类似zookeeper的多节点配置中心取代. 流量控制,流量控制是保证大流量下系统可用性的重要手段,当系统流量不足以支撑所有流量时,只保留合理的流量处理.其他流量直接丢弃,否则系统会被压垮,造成雪崩. 功能降级,另外大流量情况下,有些无关紧要的功能可以暂时降级,后期通过数据补全的方式进行修正,将核心的资源用于最关键的业务.比如双11时,为保证购买可以暂时不考虑推荐,这样省掉推荐资源

架构师速成-目录

天地会总舵,陈近南给了韦小宝一本武功秘笈,韦小宝说:"嗯?这么大一本我看要练个把月啊!" 陈近南说:"这本只不过是绝世武功的目录,那边才是绝世武功的秘笈!" 这就是架构速成的秘笈目录 架构师速成1-前言 架构师速成2-概述 架构师速成2.1-论成功 架构师速成2.2-论成功 架构师速成3-开发者境界 架构师速成4-幼儿园 架构师速成4.1-幼儿园要学会如何学习 架构师速成4.2-幼儿园要学会如何学习 架构师速成4.3-幼儿园要学会查找资料 架构师速成5-小学 架构师

架构师速成2-概述

成为一名合格的架构师,需要经历菜鸟.码农.资深码农.项目经理.技术经理.架构师等一系列的过程.为了让大家通俗易懂,我把整个过程按照大家熟知的上学的顺序排了一下,从幼儿园-小学-中学--一直到博士,至于博士后需要大家自己去实践和想象了.每个过程我都会进行统一的描述: 阶段:例如 幼儿园 需要做的事情:例如 学会一门编程语言 完成任务耗时:例如 2-5个月 升级标准:例如:能写出简单的计算器,接受用户输入的+-x/运算 风险:例如 有人打断 当然在正式开始之前,我还是要提示一下相关的风险: 任何行业

《Microsoft.NET企业级应用架构设计（第2版）》——第1章 今天的架构师和架构 1.1软件架构到底是什么

第1章 今天的架构师和架构 在计算机的最初年代,硬件成本远远大于软件成本.数十年之后,我们发现情况有了根本的变化.整个工业有了显著的进步,而硬件成本也急剧下降.另一方面,软件成本却大幅上升,这主要是因为开发自定义企业软件的复杂性提升了. 这种情况催生了一系列的准则,并以此指导工程师设计这类系统.架构这个术语源自建筑行业,现已普遍用于描述规划.设计和实现软件密集型系统的艺术.当我们两个还是青少年时,<爱是-->这部漫画(http://www.loveiscartoon.com)正值流行.每期漫画

架构师速成8.3-架构师必须要了解的规则

作为一个架构师,有些规则是必须要掌握的,这就想软件的公理,如果你学物理不知道牛顿定律,那就不要学了.在软件行业也有类似的东西,我称之为软件定律.例如: ACID,CAP,BASE ACID 传统数据库系统中,事务具有ACID 4个属性 (1)原子性(Atomicity):事务是一个原子操作单元,其对数据的修改,要么全都执行,要么全都不执行. (2)一致性(Consistent):在事务开始和完成时,数据都必须保持一致状态.这意味着所有相关的数据规则都必须应用于事务的修改,以保持数据的完整性:事务

架构师速成8.2-架构师要懂产品

产品和架构两个截然不同的职业,好像风马牛不相及,其实不是这样的.产品的思想需要经过技术的手来成为现实,在成为现实之前,需要技术理解.评估.碰撞.优化.把控.验证等等.当然架构师就承担了这一系列技术的责任,而且在一个产品的实现过程中,技术架构并不是很重要的,前期可以没有架构,简单快速验证,只有在用户多了之后,架构才有真正的用处.在初创公司,很多架构师都等不到用户多了的那一天,来实现自己的架构梦.所以产品这一关架构一定要把好,只有你把好了,后面才有机会让你去架构. 当然架构师的懂产品,是懂产品的生命