架构设计

json 简介 JSON(JavaScript Object Notation) 是一种轻量级的数据交换格式。 易于人阅读和编写。同时也易于机器解析和生成。 它基于JavaScript Programming Language, Standard ECMA-262 3rd Edition - December 1999的一个子集。 JSON采用完全独立于语言的文本格式，但是也使用了类似于C语言家族的习惯（包括C, C++, C#, Java, JavaScript, Perl, Python等）。 这些特性使JSON成为理想的数据交换语言。 JSON支持两种数据结构存在： 对象（object）：一个对象包含一系列非排序的名称／值对(pair)，一个对象以{开始，并以}结束。每个名称／值对之间使用 : 分割。 数组 (array)：一个数组是一个值(value)的集合，一个数组以 [ 开始，并以]结束。数组成员之间使用 , 分割。 具体的格式如下： [value1, value2, value3] 名称／值（pair）：名称和值之间使用 : 隔开，格式如下： {name:value} 名称必须是字符串类型； 值(value)必须是可以是字符串(string)，数值(number)，对象(object)，有序列表(array)，或者 false， null， true 的其中一种。 JSON的格式描述可以参考RFC 4627。 为什么JSON不支持 int64 类型？ 通过上面的介绍有两个关键点： JSON 是基于 JavaScript Programming Language, Standard ECMA-262 3rd Edition - December 1999的一个子集 JSON 支持number 类型 Javascript的数字存储使用了IEEE 754中规定的双精度浮点数数据类型，而这一数据类型能够安全存储 -(2^53-1) 到 2^53-1 之间的数值（包含边界值）。JSON 是Javascript 的一个子集，所以它也遵守这个规则。 ...

《代码大全》读书笔记 太长不看版 软件构建中的设计 软件设计是一项明确的活动 设计中的挑战 软件设计一词意味着去构思、创造或发明一套方案，把一份计算机软件的规格说明书要求转变为可实际运行的软件。 设计就是把需求分析和编码调试连接在一起的活动。 好的高层词设计能够提供一个可以稳妥容纳多个较低层次设计的结构。 设计是一个险恶的问题 险恶（wicked）的问题就是那种只有通过解决或部分解决才能被明确的问题。 Tacoma Narrows 大桥是一个险恶问题的好例子，因为直到这座桥坍塌，工程师才知道不应该只考虑桥的负荷，还需要充分的考虑空气动力学因素（只有建造大桥，才能从中学到需要考虑额外的环节）。 设计是一个了无章法的过程（即使它能得处清爽的成果） 是因为在设计的过程中可能会采用很多错误的步骤，多次出错 因为设计的优劣差异往往非常微妙 因为不能判断设计是否足够好 设计就是确定取舍和调整顺序的过程 现实世界中，设计者工作的一个关键内容就是衡量彼此冲突的各项设计特性，并尽力在其中寻求平衡。响应速度优先和开发时间短优先得出的设计结果可能是不同的。 设计受到诸多限制 设计的要点一部分是在创造可能发生的事情，另一部分是在限制可能发生的事情。 如果一个人有无限空间和资源来建造房子，可能会建造出无法控制的建筑。正是因为有了限制，才得出了简单的结果。软件设计也是一样。 设计是不确定的 每个人设计的结果可能是不同的，并且可能用起来都不错。设计没有标准答案。 设计是一个启发式的过程 设计过程中充满了不确定性，因此设计技术也趋于具有探索性–“经验法则”或者“试试没准能行”–而不是保证能产生预期结果的可重复的过程。 设计是自然而然形成的 设计不是在谁的头脑中直接跳出来的，它是在不断的设计评估、非正式讨论、写试经验以及修改试验代码中演化和完善的。 关键的设计概念 软件的首要技术使命：管理复杂度 本质的难题和偶然的难题 偶然的难题可以理解为bug，编程语言笨拙的语法，等易于发现容易解决的问题。 本质的难题则比较复杂，本质上说，软件开发就是不断去发掘错综复杂，相互关连的整套概念的所有细节。本质困难就是： 要面对复杂、无序的现实世界； 精确而完成的识别出各种依赖关系和外部情况 设计出完全正确而不是大致正确的解决方案 。。。 管理复杂度的重要性 一个失败的项目如果是由于技术原因而失败，通常都是因为软件复杂度失控了。如果复杂度失控，那么软件就会变得极端复杂，没有人知道它能做什么，它出了问题如何解决。 管理复杂度是软件开发中最为重要的技术话题。 在软件架构层次上，可以通过把大的系统分解为多个子系统来降低问题的复杂度，多个简单的问题比一个复杂的大问题更容易理解。 子系统相互间应该减少依赖； 子系统的关注点应该是相互分离的。 如何应对复杂度 高代价、低效率的设计源于下面三种根源： 用复杂的方法解决简单的问题 用简单但错误的方法解决复杂的问题 用不恰当的复杂的方法解决复杂的问题 用下面的方法管理复杂度 把任何人在同一时间需要处理的本质复杂度降到最低 不要让偶然性的复杂度无谓的增长 理想的设计特征 最小的复杂度 易于维护 松散耦合 可扩展性 可重用性 高扇入：让大量的类使用某个给定的类。（意味着设计出的系统很好的利用了在较低层次上的工具类 低扇出：让一个类少量或始终的使用其他类。（高扇出（7个）意味着一个类过多的使用了其他类，可能会变得过于复杂 可移植性 精简性：没有多余的部分 层次性：比如一个新系统会用到很多设计不佳的旧系统，这时就应该为新系统编写一个负责同就代码交互的层（代理模式） 层次性能把低劣的代码紧闭起来 如果能最终抛弃或重构旧代码，旧不必修改处交互层之外的任何新代码。 标准技术：用到的外来的、古怪的东西越多，也越难理解。 设计的层次 1. 软件系统（Software System） 2. 分解为子系统或包（Division into Subsystems or Packages） 这一层的主要目的是确定如何把程序分为主要的子系统，并定义清楚允许各子系统如何使用其他子系统。 ...

场景：现在需要开发一个前后端分离的应用，后端采用 RESTful API 最为方便，但是如果这个后端服务会在一天中的某些时候有高并发的情况，使用什么样的架构最为简单呢？ 刚思考这个问题的时候我想到的解决方案可能有以下几种： 使用CDN内容分发网络，减少主服务器的压力 使用LVS服务器负载均衡 使用缓存 硬件层 提高带宽，使用SSD 硬盘，使用更好的服务器 代码层，优化代码（使用性能更好的语言等 ​ 但以上的几个方法都需要关注服务器的存储和计算资源，以便随时调整以满足更高的性能，并且高并发的请求也是分时段的，配置了更高性能的服务器在访问量变低的时候也是资源浪费。 这个时候可以使用 FaaS（Functions as a Service） 架构，跟传统架构不同在于，他们运行于无状态的容器中，可以由事件触发，短暂的，完全被第三方管理，功能上FaaS就是不需要关心后台服务器或者应用服务，只需关心自己的代码即可。其中AWS Lambda是目前最佳的FaaS实现之一。 AWS Lambda AWS Lambda 是一项计算服务，使用时无需预配置或管理服务器即可运行代码。AWS Lambda 只在需要时执行代码并自动缩放。借助 AWS Lambda，几乎可以为任何类型的应用程序或后端服务运行代码，而且无需执行任何管理。现在 AWS Lambda 支持 Node.js、Java、C# 和 Python。 使用场景 Lambda 常见的应用场景有以下几种： 将Lambda 作为事件源用于 AWS 服务（比如音频上传到 s3后，触发 Lambda 音频转码服务，转码音频文件 通过 HTTPS (Amazon API Gateway) 实现的按需 Lambda 函数调用（配合 API Gateway创建简单的微服务 按需 Lambda 函数调用（使用自定义应用程序构建您自己的事件源） 计划的事件（比如每天晚上12点生成报表发送到指定邮箱 下图是将Lambda 作为事件源用于 AWS 服务案例的一个执行流程图： 用户将对象上传到 S3 存储桶（对象创建事件）。 Amazon S3 检测到对象创建事件。 Amazon S3 调用在存储桶通知配置中指定的 Lambda 函数。 AWS Lambda 通过代入您在创建 Lambda 函数时指定的执行角色来执行 Lambda 函数。 Lambda 函数执行。 这篇文章主要介绍 将 Lambda 作为事件源用于 AWS 服务 和 配合 API Gateway 创建简单的微服务。 ...