随笔分类 - 架构设计
介绍java架构相关的文章
摘要：在上一篇文章里面提到了 《跨行清算的实现原理》，这次来分析一下线下支付的场景和流程。今天看到一篇文章：http://www.huxiu.com/article/23248/1.html?f=chouti 银泰和支付宝线下合作，推广支付宝当面付款的功能其实仔细分析一下，觉得当面付这个功能说实在的，对消费者来说，并没有太大的优势，主要表现在以下几点：1 当面付的资金要么从支付宝余额支付，要么从关联的快捷银行卡支付。对于大多数用户来说，直接使用信用卡支付即可，为什么要经过支付宝钱包绕一圈，人为增加了一道手续。2 线下支付最重要的是支付效率，从个人经验来看，银行卡的支付效率是除现金之外，目前线下支付场
阅读全文
摘要：最近看了很多银联方面的清算系统的设计原理，对于跨行清算系统有了很大的了解，写这篇文章的目的是在于从一个程序员的角度去思考一个跨行清算系统的架构是如何实现的以及整个过程中我们有哪些思想是可以借鉴的。由于金融里面涉及到太多的专业名词，包括借贷，备付金，头寸，调拨等等，这里不会涉及到这些，取而代之的是以大家可以理解的概念去解释。下面简单的介绍一下两种跨行清算系统的实现原理以及特点。一种跨清算系统是我们最熟悉的银联，还有一种是越来越流行的第三方支付系统，比较典型的是快钱。首先来拿生活中的一个非常常见的例子来说明跨行清算的整个过程，这里面不涉及交易费等其他概念。跨行取款流程张三是工行的持卡人，他需要取现
阅读全文
摘要：最近在项目里面遇到一个比较难以解决的问题，简单的说就是查询问题。某一张表的数据量比较大，很多业务都会根据条件来查询相关的数据，查询主要分为两类，一类是业务查询，能够根据指定的条件查询出相关的数据，数据量比较小，查询速度快，一类是后台查询，偏向数据分析，特点是查询耗时长，查询数据量比较大。由于大量系统访问这个数据库，那么对数据源连接的实时性要求就比较高，如果后台查询大量占用数据源的连接，会影响到外部业务，从而影响业务功能的稳定性。如何解决这个问题，在一般的情况下，我们首先会考虑设置一个合理的超时时间，由于业务查询都是大多是根据关键字查询，耗费时间都会在几十毫秒之下，很少会有大量长耗时的sql，后
阅读全文
摘要：这段时间一直都在学习python，主要目的还是打算学习一门互联网的编程语言，为后续的职业生涯做一些规划，毕竟java在互联网除了电商领域有叫广泛的使用场景之外，在互联网其他领域还不是很普及，并且java太重量级了。而python在相对来说轻量级并且易于使用，很适合互联网产品快速迭代开发方式。个人之前接触的唯一一个纯面向对象编程语言就是java，以至于很长一段时间内，我都以为面向对象编程的模型应该都是以java这样为基础的，直到看了javasript和python等以函数式编程为主，支持面向对象编程的语言，才更深的了解面向对象的编程本质。什么是对象，对于对象的理解，我感觉就是具有某些特性的物质，
阅读全文
摘要：所谓道，就是事物的基础和本质，是一种思想和理论，是不易改变的部分。所谓术，就是具体实现的方法和手段，是一种实践的过程，是容易改变的部分。在科学发展的过程中，一般都是先从术开始，开始解决某一个具体的问题，从研究这个具体问题所用的方法，研究这个问题后背的本质，从而推导出一些基础理论和思想，再有这个基础理论，应用到实践，交替的发展。之所以说这个话题，主要是在回顾这些年自己的技术生涯中存在的问题以及思考如何再进一步提高我们的技术水平。个人觉得学习的过程应该是和科学的发展规律是类似的，先从解决一系列具体的问题入手，在思考这些问题后背的本质是要解决哪些基础问题，在抽象出来这些问题背后的本质，进而思考这一类
阅读全文
摘要：在最近做的一个项目中，由于每天核算的数据量过于庞大，需要把数据库进行分库保存。当数据分散到各个库之后，带来的数据更新操作就会存在一个一致性和完整性的问题。下面是一个典型的场景假设目前存在三个物理库，现在有一个文件，里面有1W条数据，根据分库的规则，可以把文件里面的数据分到三个库中，现在需要保证这1W条数据要要完整的保存到这三个库里面，并且数据是一致性的，也就是说 三个库里面已导入的数据完全和文件里面的数据一致。正常情况下，我们先把文件里面的数据按照所属的数据库分成三份，然后针对每一份数据库进行保存，在单库的情况下，可以保证单库的数据完整性。但是三个库要保证一致性，就是非常复杂的一项工作，很有可
阅读全文
摘要：最近在做一个项目，其中一个方案涉及到跨库事务一致性问题，是一个简单的场景。这个项目是对老的业务进行性能提升，业务逻辑基本上保持不变。主要是在于新项目采用了分库分表的设计，从而提升了性能。考虑到项目发布之后可能存在风险，采取了新老系统的并行方案。这个系统的业务比较简单：接收来自外部的数据，然后对数据进行核对处理。为了保证新老系统能够并行，在接收数据的时候必须实现双写方案，从而导致了跨库事务的一致性问题。下面一幅图展示这一简单的场景这里面会存在一个小问题，就是可能存在写入老库成功，但是写入新库失败的场景。我们假设出现这种概率的情况是百万分之一，在系统发布的情况下，这种概率可能更高。从目前我们的数据
阅读全文
摘要：最近看了很多公司架构的演变的文章，发现其中的基本思路和架构演变都很类似，这里也总结一下数据库架构的演变以及演变背后的思路。单主机最开始网站一般都是由典型的LAMP架构演变而来的，一般都是一台linux主机，一台apache服务器，php执行环境以及mysql服务器，一般情况下，这些都在一台虚拟主机上，简称单主机模式。单主机模式缺点：1 web服务器和mysql服务器公用一台主机，共享硬件资源，可能存在某一方资源征用太大，导致整个应用产生瓶颈2 当业务增长之后，没有办法做到横向扩展。3 容错性太差，一旦主机存在问题，整个应用不可用独立主机随着业务的发展，可以把mysql服务器和web服务器主机分
阅读全文
摘要：在前面三篇文章中，介绍了关于分布式系统中数据一致性的问题，这一篇主要介绍CAP定理以及自己对CAP定理的了解。CAP定理是2000年，由Eric Brewer 提出来的Brewer认为在分布式的环境下设计和部署系统时，有3个核心的需求，以一种特殊的关系存在。这里的分布式系统说的是在物理上分布的系统，比如我们常见的web系统。这3个核心的需求是：Consistency，Availability和Partition Tolerance，赋予了该理论另外一个名字 －CAP。Consistency：一致性，这个和数据库ACID的一致性类似，但这里关注的所有数据节点上的数据一致性和正确性，而数据库的AC
阅读全文
摘要：这一几天一直在回顾事务相关的知识，也准备把以前了解皮毛的知识进行一些深入总结，虽然这一些知识并没有用到，但是了解其实现原理还是很有必要的，因为知道了原理，你也能把它实现出来。在上一节事务的编程模型里面，主要说明了三种编程模型，一般情况下，我们都接触的是单一资源的事务，也就是单独对一个数据库进行操作。如果需要跨多个资源保证事务一致性举个例子：在ATM机取钱的时候，需要对用户的账户进行扣款处理，然后发送一条消息给消息服务器（假设消息服务器是用JMS实现的），由消息服务器异步通过短信通知用户。如果用户取款失败，那么消息服务器不应该发送短信给用户。如何保证 用户帐务扣款 和 消息服务器的消息保持一致性
阅读全文
摘要：在上一篇文章里面写了关于事务的一些特性，这里在谈谈事务的编程模型。什么叫做事务的编程模型，这个问题比较难以回答，其实简单的一句话，就是我们如何去使用和控制事务。在java平台里面，有三种事务编程模型：本地事务模型，编程式事务模型，声明式事务模型（当然我不是太认同这种说法，并不是太准确，不过大体也就这么回事情）本地事务模型本地事务模型：不用事务的编程框架来管理事务，直接使用资源管理器来控制事务。典型的就是java.sql.Connection 中的 setAutoCommit、commit、rollback方法，见下面一段代码，直接使用资源管理器进行事务控制 Connection ...
阅读全文
摘要：今天在《外刊IT评论》里面看到这样一篇文章 《一个程序员怎么能做出这样的事情》 ，觉得作者的观点非常有意思，下面看看文章中的一段代码public void Execute() { ArrayList empIds = PayrollDatabase.GetAllEmployeeIds(); foreach (int empId in empIds) { Employee employee = PayrollDatabase.GetEmployee(empId); ...
阅读全文
摘要：在NoSql和内存数据库如此流行的今天，在谈关系型数据库的貌似有点落伍了，不过在传统软件行业和对数据一致性和安全性要求比较高的行业，关系型数据库还是比较普遍的。正好最近看到一个数据库事务相关的知识，自己在这几年的工作中用的比较多，也在事务上面犯过很多的错误，正好借这个机会整理以下。事务的ACID属性A(Atomicity)原子性： 在一个事务上下文里面，对数据库进行的任何操作，必须保证是原子的，也就是说要么不做，要么全部都做，不能只做一部分。比如insert一条数据和delete一条数据，不知能只做insert操作而不做delete操作C(Consistency)一致性：在事务的处理过程中,数
阅读全文
摘要：在分布式系统的数据一致性问题（一）里面，简单的介绍了分布式数据的同步问题，上面的问题比较抽象，在目前的互联网应用中还很少见，这次在通过一个比较常见的例子，让大家更深入的了解一下分布式系统设计中关于数据一致性的问题这次我们拿我们经常使用的功能来考虑吧，最近网购比较热门，就以京东为例的，我们来看看京东的一个简单的购物流程用户在京东上下了一个订单，发现自己在京东的账户里面有余额，然后使用余额支付，支付成功之后，订单状态修改为支付成功，然后通知仓库发货。假设订单系统，支付系统，仓库系统是三个独立的应用，是独立部署的，系统之间通过远程服务调用。订单的有三个状态：I:初始 P:已支付 W:已出库，订单金额
阅读全文
摘要：最近写了一个关于 铁道部购票系统的若干文章铁道部新客票系统的设计（一）铁道部新客票系统的设计（二）铁道部新客票系统的设计（三）正好遇到一个博友，咨询了一个问题，这个问题正好可以作为分布式系统的数据一致性的简单例子，当然，这个只是比较简单的情况现在先抛出问题，假设有一个主数据中心在北京M，然后有成都A，上海B两个地方数据中心，现在的问题是，假设成都上海各自的数据中心有记录变更，需要先同步到主数据中心，主数据中心更新完成之后，在把最新的数据分发到上海，成都的地方数据中心A，地方数据中心更新数据，保持和主数据中心一致性（数据库结构完全一致）。数据更新的消息是通过一台中心的MQ进行转发。先把问题简单化
阅读全文
摘要：铁道部新客票系统的设计（一）铁道部新客票系统的设计（二）铁道部新客票系统的设计（三）最近只是一时兴起，觉得无聊，正好要到买票的时候，写了这个一系列文章，首先是对自己这些年来的工作经验的总结，其次是把分布式事务性系统的设计思想进行分析和整理，最后也就是和想集大家的智慧，讨论系统的设计。我不是铁道部的工程师，我只是一家互联网金融类公司的屌丝工程师，级别不高，能力也一般，就是喜欢技术而已。在第二篇文章里面，重点分析了余票库的整体设计，我看到有的评论说了几点，现在整理一下1 为什么要用悲观锁为什么要用锁，由于之前是做金融系统，对数据的一致性要求很高。铁道部的出票操作要保证数据一致性，所以必须在获取余票
阅读全文
摘要：铁道部新客票系统的设计（一）铁道部新客票系统的设计（二）铁道部新客票系统的设计（三）在上一篇文章中 铁道部信客票系统设计（一） 里面，探讨了关于数据库层面的功能性需求以及非功能性的需求，在非功能性需求里面，一博主 提出了没有考虑到峰值的情况，这一点的确漏掉了，因为我们铁道部的特殊需求，在春运期间负载很大，平时可能一般，如果用考虑最大的情况，则回存在浪费的情况，如果考虑不足，就像网络订票一样，苦逼。就好比 铁道部春运的时候，发车量大，但是如果制造大量列车，平时就空闲了，也就很亏。机器的折旧很是块的。春运期间可以考虑紧急扩容来实现，所以从设计上可以保持这种扩展性。 扩容是一项工程，整体来说比较复杂
阅读全文
摘要：铁道部新客票系统的设计（一）铁道部新客票系统的设计（二）铁道部新客票系统的设计（三）这几天正好看到一条新闻铁道部:新客票系统2015年建成 ，正好最近想整理和总结一下这几年的工作中的收获，正好可以借这个机会，尝试设计一下铁路客票系统，把自己所学全部用到这个系统中去，顺便也希望各位猿们拍砖，一起探讨一下设计，技术吗，讨论讨论总是有点收获的，总比一个人在那里看书好。非功能性要求废话不说，这里先脱离系统的整体架构，后续在不断完善整体架构，这里首先讨论的是数据库层面的设计，因为对于整个架构系统来说，数据库的设计是最为关键重要的，数据库的设计好与坏，决定了整个系统的性能，可用性，扩展性。在考虑数据库的设
阅读全文
摘要：采用面向服务的架构设计的系统，随着服务越来越多， 面向服务的架构也会带来的副作用，会有盲区，也会有雷区副作用：1 业务被分成独立的单元，服务高度的自组织性，每个人只关于自己负责的单元，自己提供的服务和引用其他单元的服务，缺乏对系统整体的了解。而对整体视图了解的人相对决定业务的质量。2 沟通成本比较高，虽然开发可以并行，但是由于沟通的成本，导致效率低下。盲区：从战略目标到最后业务的实现，由于业务分割成多个独立的单元，每个单元的理解程度不一样，导致最后业务偏离整体目标。例如战略目标是100%，不同单元的理解程度为90%，如果有5个单元，目标会有90%*90%*90%*90%*90% = 59%雷区
阅读全文
摘要：随着公司的架构逐步发展，越来越多的问题被提出来，也发现一个良好的技术架构需要考虑的问题1 架构的可扩展性这里面又包括以下几个方面水平垂直可拆分服务无状态数据可缓存可异步处理（提高性能）可复制（提高效率）无单点设计2 架构的可管控性这里面又包括以下几个方面服务可监控性支持服务降级升级故障可隔离（可禁用）发布可回滚3 架构的可测性可测试4 架构的可部署应用程序和数据可分开部署支持多数据中心的支持多异地灾备以上就是一些技术架构需要考虑的问题，可能对于每个点不同的业务，不同的系统要求不一样，但是总体来说，都是作为一个架构师要考虑的。
阅读全文