系统设计

Soft skills are always hard than hard skills. 软技能比硬技能难。 老板听说最近流行“微服务”，问架构师咱们的系统要不要来一套？老板又听说最近流行“中台系统”，问架构师咱们要不要搞起来？其实，这些问题不用老板问，关注技术发展趋势的架构师每当听到新的技术或解决方案，都会暗中思忖是否应用到系统中。然而，用或不用，总不能凭感觉吧。此时，如果你能灵活运用康威定律，那么做出的判断将更加完美。 康威定律 康威定律是马尔文·康威1967提出的：“设计系统的架构受制于产生这些设计的组织的沟通结构。”通俗的来讲：产品必然是其（人员）组织沟通结构的缩影。 跨部门沟通是非常难的，系统各个模块的接口也反映了它们之间的信息流动和合作方式。 康威定律可谓软件架构设计中的第一定律，起初只是在杂志上的发表，后经过《人月神话》这本软件界圣经的引用，并命名为康威定律（Conway’s law），因此得以推广。 只通过简单的描述可能无法理解康威定律的精髓所在，原文中康威定律可总结为四个定律： 第一定律 组织沟通方式会通过系统设计表达出来。 第二定律 时间再多一件事情也不可能做的完美，但总有时间做完一件事情。 第三定律 线型系统和线型组织架构间有潜在的异质同态特性。 第四定律 大的系统组织总是比小系统更倾向于分解。 第一定律 Communication dictates

一、抽象 抽象是一种设计技术，说明一个实体的本质，而忽略不重要的方面。抽象将复杂的现象简化到可以分析、理解的程度。软件工程中从软件定义到软件开发要经历多个阶段，每前进一个阶段都可以看作是对软件解法的抽象层次的一次细化。抽象的最底层就是实现该软件的源程序代码。在进行模块化设计时也可以有多个抽象层次，最高抽象层次的模块用概括的方式叙述问题的解法，较低抽象层次的模块是对较高抽象层次模块对问题解法描述的细化。 二、模块化 模块在程序总是数据说明、可执行语句等程序对象的集合，或是单独命名和编址的元素。模块化是指将一个待开发的软件分解成若干个小的简单部分 -- 模块，每个模块可独立开发、测试，最后组装成完整的程序。只是一种分而治之的原则。模块化的目的是使程序的结构清晰，容易阅读、理解、测试和修改。 三、封装 封装是开发程序结构时使用的法则，每个程序的成分封装在一个单一的模块中，在定义每个模块时尽可能少的显露内部的处理。 封装对提高软件的可修改性、可测试性和可移植性有重要的作用。 四、模块独立 模块独立是指每个模块完成一个相对独立的特定子系统，并且与其他模块之间的联系简单。模块独立有两个标准：耦合性和内聚性。 1、耦合是模块之间的相对独立性（相互之间的紧密程度）的度量。耦合取决于各个模块之间接口的复杂程度、调用模块的方式以及通过接口信息类型等。 耦合按从弱到强的顺序分为以下几种： 非直接耦合

差错帐处理是支付系统设计中查漏补缺的一环，那它具体讲了些什么呢？一起来看看~ 当日反交易 概念简述 当日反交易是把当日初始凭证下所有后续业务登记（包括该初始凭证本身）所产生的账务流水和会计分录分录整套全部抹掉，适用场景特殊，特别是对于批量销帐类业务，慎用。 进行反交易处理后，如该初始凭证下存在未销帐的挂帐凭证，也是不允许对其进行后续销帐业务登记处理的。 业务校验规则 被反交易凭证必须是当前日所产生的； 被反交易凭证以及其后续其他业务登记凭证状态必须全部是复核通过并处理结束； 已经被隔日冲正过业务凭证不能被反交易； 已被反交易过的业务凭证不允许被冲正； 补偿校验，必须通过会计核心业务校验：允许对所选择的凭证进行反交易。 系统数据反映 源帐户指所有分录所对应的帐户，源金额指所对应的发生额； 会计平台中借贷方均为空，发生额为 0 ； 不需要同步对帐中心流水； 不产生新的账务流水，只在原流水上做抹账标记并反向更新帐户余额，被抹账的分录所对应的账务流水至少对前台用户不可见； 不产生新的红、蓝字分录； 对于红字或打上抹账标志的账务流水以及分录都不做更新。 注：不需要同步对账中心流水 举例：反交易是针对整套业务（依据原始业务凭证）进行反交易，仅限于整套都是当日的业务（可以包含当日正常和登记以及当日后续单边抹账产生的分录），反交易成功后账户明细和分录都将不体现，但记录反交易日志。 凭证详细信息：

软件生命周期概念： 软件生命周期是软件的产生直到报废或停止使用的生命周期。软件生命周期内有问题定义、可行性分析、总体描述、系统设计、编码、调试和测试、验收与运行、维护升级到废弃等阶段，也有将以上阶段的活动组合在内的迭代阶段，即迭代作为生命周期的阶段。 软件生命周期举例： B2C电子商务网站建设的一般过程 (一)系统规划阶段 系统规划阶段的任务是对企业的环境、目标、现行系统的状况等进行初步调查，根据企业目标和发展战略，确定信息系统的发展战略，研究新系统的必要性和可能性。在这个阶段给出备选方案，并进行可行性分析，写出可行性分析报告。待可行性分析报告审议通过后，编制系统设计任务书。 1、需求分析 为了进行可行性研究分析，首先对电子商务系统的需求进行分析。通过对企业的需求进行调查，明确电子商务网站需要做什么，做到什么程度。在此，通过查阅资料、实地观察、业务专题报告等方法将该电子商务网站的需求归纳为功能需求和性能需求。 功能需求：B2C电子商务网站就是Business To Consumer，也就是企业借助于Internet建立网点进行交易的一个系统。流程上，店家发布产品信息，消费者在线选购、在线支付，通过物流最后达成交易。所以从购买方看，需满足消费者在线选购、在线支付等；从销售方看，要能让店家整理网上商品、管理订单等。 性能需求：系统运行要稳定，在不同的系统中能正常运行，具有较强的适应性

学习目标 1.熟悉Linux系统下的开发环境 2.熟悉vi的基本操作 3.熟悉gcc编译器的基本原理 4.熟练使用gcc编译器的常用选项 5.熟练使用gdb调试技术 6.熟悉makefile基本原理及语法规范 7.掌握静态库和动态库的生成与调用方法 8.理解C程序中模块的概仿，模块分解的“高内聚，低耦合”的原则 9.了解链接的概念 -gcc简介： GNU CC（简称为gcc）是GNU项目中符合ANSI C标准的编译系统，能够编译用C、C++和Object C等语言编写的程序。gcc又是一个交叉平台编译器，它能够在当前CPU平台上为多种不同体系结构的硬件平台开发软件，因此尤其适合在嵌入式领域的开发编译。 -编译过程： 预处理： gcc –E hello.c –o hello.i;gcc –E 调用cpp 编 译： gcc –S hello.i –o hello.s;gcc –S 调用ccl 汇 编： gcc –c hello.s –o hello.o;gcc -c 调用as 链 接： gcc hello.o –o hello ;gcc -o 调用ld -gdb： 注意使用GCC编译时要加“-g”参数。 GDB最基本的命令有： gdb programm (启动GDB) b 设断点（要会设4种断点：行断点、函数断点、条件断点、临时断点） run 开始运行程序 bt 打印函数调用堆栈 p

开发单体应用时，相信大家都有使用过数据库的 本地事务 ，也就是在同一个数据库中，可以允许一组操作要么全都正确执行，要么全都不执行。这里特别指出了本地事务，也就是说明数据库事务只支持同一个数据库的操作。可随着技术和业务发展，一方面随着系统业务量增大，数据库存储东西越来越多。当达到一定数据量时，为了应对高并发，就会出现分库分表需求。另一方面，随着服务化方案的推广，越来越多的公司团队将原有的大项目拆分成一个个小应用，这也使得跨应用（JVM）数据库场景出现。可是目前数据库不支持跨库事务，我们应该如何实现分布式事务呢？本文首先会为大家梳理分布式事务的基本概念和理论基础，然后介绍几种目前常用的分布式事务解决方案。 一、定义 百度百科给出的定义：“分布式事务就是指事务的参与者、支持事务的服务器、资源服务器以及事务管理器分别位于不同的分布式系统的不同节点之上。”简单的说，就是一次大的操作由不同的小操作组成，这些小的操作分布在不同的服务器上，且属于不同的应用，分布式事务需要保证这些小操作要么全部成功，要么全部失败。本质上来说，分布式事务就是为了保证不同数据库的数据一致性。 二、事务的四大特性 ACID 1.原子性 原子性要求，事务是一个不可分割的执行单元，事务中的所有操作要么全都执行，要么全都不执行。 2.一致性 一致性要求，事务在开始前和结束后，数据库的完整性约束没有被破坏。 3.隔离性

现在几乎大部分的 App 都支持使用多个第三方账号进行登录，如：微信、QQ、微博等，我们把此称为多账号统一登陆。而这些账号的表设计，流程设计至关重要，不然后续扩展性贼差。本文不提供任何代码实操，但是梳理一下博主根据我司账号模块的设计，提供思路，仅供参考。 一、 自建的登陆体系 1.1 手机号登陆注册 该设计的思路是每个手机号对应一个用户，手机号为必填项。 流程： 首先输入手机号，然后发送到服务端。先判断该手机号是否存在账号，如果没有，就会生成随机验证码，将手机号和验证码绑定到 Redis 中，并设置一定的过期时间（过期时间一般是5分钟，这就是我们一般手机验证码的有效期），最后将验证码通过短信发送给用户。 用户接收到验证码后，在界面填写验证码以及密码等基础信息，然后将这些数据发送服务端。服务端收到后，先判断在 Redis 里面这个手机号对应的验证码是否一致，，失败就返回错误码，成功就给用户创建一个账号和保存密码。 注册成功后，用户即可通过自己的 手机号+密码 进行登陆。 问题： 用户体验差，需要完成获取验证码，填写验证码/密码/用户名等诸多的信息完成注册，然后才能使用； 容易遗忘密码，遗忘后，只能通过忘记密码来重新设置密码。 1.2 优化注册登陆 该方案的思路是弱化密码的必填性，即无论用户是否注册过，可通过 手机号 + 验证码 直接进行登陆(保留 手机号 + 密码 登录的方式)。

2012年Q3-Q4，经过一段时间的调整，终于将系统中的产品ID参数剔除，代之以模型ID，交互以model id作为媒介将数据提供给上层产品系统去使用。尽管这是一件很小的细节变化，但是却使得我们的系统结构、层次更加清晰，能够使下层的服务提供者，摆脱快速变化的业务系统的束缚，让两者都能快速的发展而不相互影响。 在比较大的应用系统体系以及快速发展的业务面前，我们的系统设计往往会因为为了快速响应业务需求而变得不那么清晰，在业绩与系统设计上，有时候我们会被产品说服而选择做一些更直接的方式，但是这种方式在长期的系统发展中却会变成难以突破的壁垒。因此，做好业务的同时，也要做好自己的方案、领域设计。即使有时候我们用了权宜之计，但是我们也要在后期将之改变，否则积重难返，很可能连重构的机会都没有。唯一的解决方式就是redo。 来源： http://www.cnblogs.com/walkongrass/archive/2013/01/10/2854610.html

上一篇文章讨论了分布式系统中的服务调用和异步消息，今天想在这两个的基础上讨论下分布式系统需要解决的问题，以及常见的解决方案。 其实分布式系统的出现和分布式系统面临的挑战归结到最终都是因为用户数量的急剧增长导致的，随着用户数量和活跃用户数的，应用服务和数据库服务的并发访问压力越来越大，我们不得不进行服务拆分，做数据库的拆分和读写分离。服务拆分之后可以让我们能对每个服务进行针对性的部署，核心服务得到更好的隔离。 对于服务的拆分，我们可以根据领域驱动设计的思想，将整个系统进行域的划分，找出我们的核心子域、支撑子域；服务拆分之后面临的一个问题是服务之间的调用，此时RPC就出现了（当然此前还有webservice等技术），而随着RPC的出现，又带来了新的问题，就是服务的治理，例如新的服务上线之后如何让其他服务发现，服务下线之后如何剔除，服务调用超时之后如何进行处理，还有就是服务的性能监控和可用率监控以及相应的报警措施。 同时，有些场景下可能我们不需要同步的调用一些服务，只需要异步通知就可以了，虽然现在的RPC框架也可以实现异步调用，但是当异步调用失败后还是会影响到通知的准确性，于是就有了消息队列。消息队列可以让我们实现服务之间的异步调用，当需要做某一个通知时，我们只需要往消息队列的服务方发送一条消息，用一个消费者去消费这条消息然后调用其他服务即可。同样每一项技术的引入都会给我们带来新的问题

正式内容开始前的一点题外话： 去年毕业，到上个月13号工作正式满一年了，在工作开始之初就想着要多写博客，后来慢慢发现，自己没啥积累，即使写也是CV别人的，没多大意义，于是就放弃了写博客，专心提升自己。直到最近看了一些关于分布式系统设计的文章，才想好好总结总结，于是有了这篇难产的博文。 下面就开始胡诌了。 1、什么是分布式系统？为什么会有分布式系统？ 我理解分布式系统就是将多台服务器按某种规则组合在一起，以期望获得更大的请求处理能力，让系统更加的稳健，不会因为某些故障导致系统的不可用。 在分布式系统出现之前，我们的系统都会面临两个问题，一个单机瓶颈，还有一个是单机故障： 单机瓶颈就是一台机器的处理能力是有限的，随着业务的发展，更多用户的访问使得单机无法处理更多的请求，由此造成用户体验的下降、用户流失； 单机故障就是当我们将服务部署到一台机器上后，万一服务器所在区域停电了、服务器网线断了，总之因为各种各样的原因，导致服务器宕机、网络不通，这样都会导致服务不可用 解决以上两种问题的办法就是加机器，对于第二种情况除了加机器之外，我们可能还需要多机房灾备、更甚至的就是异地多活，博主所在公司去年就在主推异地多活。将多台服务器通过网络组合在一起，形成一个分布式系统。 而我们根据服务器功能的不同可以将这些分布式系统细分为：分布式服务系统（包括微服务、消息服务、搜索服务等）、分布式缓存