一、面向服务的架构（SOA service oriented architecture）
RPC的全称是Remote Process Call，远程过程调用。
无论是何种类型的数据，都要转换成二进制在网络上进行传输。将对象转换成二进制称为对象的序列化，将二进制恢复为对象称为反序列化。
Hessian比java内置的序列化 效率高很多。
转换成json或者xml
通过HttpClient发送Http请求
两种主要的url链接风格，一种是RPC风格，一种是REST风格。
RPC的url直接在http请求的参数中标明需要远程调用的服务接口名称、服务需要的参数；
REST通过Http请求对应的POST、GET、PUT、DELETE来完成对应的crud操作。
POST 创建、GET获取信息、PUT更新、DELETE删除
分布式应用架构体系对于业务逻辑的复用需求很强烈，上层业务都想借用已有的底层服务，来快速搭建更多、更丰富的应用。公共的业务被拆分出来，形成可共用的服务，最大程度的 保障代码和逻辑的复用，避免重复创建，这种设计称为SOA。
请求到来时，将请求均匀分配到后台服务器，负载均衡服务器从服务对应的地址列表中，通过相应的均衡算法和规则，选取一台服务器进行访问，这个过程称为服务的均衡负载。
常见的均衡负载算法包括轮询法、随机法、原地址哈希法、加权轮询法、加权随机法、最小连接法等。
轮询法（Round Robin）：将请求按顺序轮流分配到后端服务器，均衡的对待服务器，不关心服务器的连接数和实际负载。（需要保存轮询的位置，需要加锁，影响系统吞吐量）
随机法（Random）：根据后端服务器列表的大小值随机取一个，根据概率统计理论，随着数量的增多，越来越接近平均分配流量到后台服务器。
原地址哈希法（Hash）：获取客户端访问的ip地址，通过哈希算法获得一个值，用该值对服务器列表长度进行取模运算，
加权轮询法（Weight Round Robin）：给配置高、负载低的机器配置更高的权重，让其处理更多的请求，而低配置的机器则降低负载。
加权随机法（Weight Random）：根据后端服务器不同的配置和负载情况，配置不同的权重。
最小连接法（Least Connection）：后台服务器的请求有快有慢，根据连接情况，选择连接数最少的服务器来处理请求。
服务网关
二、分布式系统基础设施
分布式session：将session统一存储在分布式缓存中，可以保证较高的读写性能。
Mysql的拓展
1、业务拆分
2、复制策略
随着访问量增加，某个库的压力越来越大，可以将数据复制到数据库服务器上，前端通过访问Mysql集群中任意的一台服务器，能够读到相同的数据。
3、分库分表
当数据库单表的记录数达到千万级别甚至亿级且数据库面临极高的并发访问，需要对表的吞吐能力做拓展。
减少单表的记录数，减少查询所需时间，提供数据库的吞吐量。
分表能够解决单表数据量过大导致查询效率下降问题，但无法解决并发的读写访问。对数据库进行拆分，提高数据库的写入功能，这就是分库。
3、互联网安全架构
安全算法包括摘要算法、对称加密算法、非对称加密算法、信息编码。
摘要算法：MD5、SHA、Base64（可逆，不安全）
对称加密算法(安全性和秘钥有关)：DES、3DES、AES
非对称加密算法：需要两个秘钥，一个公开秘钥，一个私钥。RSA算法
数字签名：MD5withRSA、SHA1withRSA
数字证书包括对象的名称、证书的过期时间、证书的颁发机构、颁发机构对证书的数字签名、签名算法、对象的公钥
4、系统稳定性
日志分析常用命令：1）查看文件内容 cat ab.txt；
2）、分页显示文件 less access.log；
3）、显示文件尾 -f 该参数用于监视File文件增长 ；-n Number 从 Number 行位置读取指定文件 tail -n2 -f access.log;
4）、显示文件头 head -n20 access.log；
5）、内容排序 -n 依照数值的大小排序 -k排列的列 -t参数指定列分隔符 -r 以相反的顺序来排序 sort -k 2 -t ’ ’ -n access.log
6）、字符统计 -c 统计字节数 -l 统计行数 -m 统计字符数 -w 统计字数 wc -l access.log
7)、查看重复出现的行 -c或–count 在每列旁边显示该行重复出现的次数;-u或–unique 仅显示出一次的行列;-d或–repeated 仅显示重复出现的行列 sort uniq | uniq -c -u
8)、字符串查找 -c ：显示总共有多少行被匹配到了;-n ：显示行号;–color :将匹配到的内容以颜色高亮显示 grep -c qq access.log 支持正则表达式
9）、文件查找 find path -option [ -print ] [ -exec -ok command ] {} ;
path: find命令所查找的目录路径;-print： find命令将匹配的文件输出到标准输出;-exec： find命令对匹配的文件执行该参数所给出的shell命令
-name filename #查找名为filename的文件
find . -print 打印当前目录所有文件
find ./name/log -name access.log
10)、归档文件 -c: 建立压缩档案;-f: 指定包的名字；-v：显示所有过程
tar -cf aa.tar file god
tar -xf aa.tar
11)、url访问的工具
curl [option] [url]
-A/–user-agent 设置用户代理发送给服务器
-b/–cookie <name=string/file> cookie字符串或文件读取位置
-c/–cookie-jar 操作结束后把cookie写入到这个文件中
-C/–continue-at 断点续转
-D/–dump-header 把header信息写入到该文件中
-e/–referer 来源网址
-f/–fail 连接失败时不显示http错误
-o/–output 把输出写到该文件中
-O/–remote-name 把输出写到该文件中，保留远程文件的文件名
-r/–range 检索来自HTTP/1.1或FTP服务器字节范围
-s/–silent 静音模式。不输出任何东西
-T/–upload-file 上传文件
-u/–user <user[:password]> 设置服务器的用户和密码
curl http://www.linux.com >> linux.html （使用linux的重定向功能保存）
curl -o linux.html http://www.linux.com （可以使用curl的内置option:-o(小写)保存网页）
curl -o /dev/null -s -w %{http_code} www.linux.com （测试网页返回值）
12)、cut
-d 自定义分隔符，默认为制表符。
-f 与-d一起使用，指定显示哪个区域
cut：以某种方式按照文件的行进行分割
cat song.txt |cut -f 1 -d " "
5、数据分析
本章要介绍和解决的问题：
1）、分布式系统中日志收集系统的架构；
2）、通过Storm进行实时的流式数据分析；
3）、通过hadoop进行离线数据分析，通过Hive建立数据仓库；
4）、将关系型数据库中的数据导入HDFS，已经将HDFS中的数据导入到关系型数据库；
5）、将分析好的数据以图形的形式展示给用户。
进行数据分析前，必须先对各个运行系统上的日志进行收集。将收集好的数据发送到统一的系统进行分析和处理，筛选出有价值的内容，进行可视化展现。
对于日志收集，最常用的方式便是轮询。通过设置一个时间间隔，不断读取文件，直到尾部。Inotify API用于检测文件系统变化的机制。Inotify可用于检测单个文件，也可以检测整个目录。当检测的对象是一个目录的时候，目录本身和目录里的内容都会成为检测的对象。
此种机制的出现的目的是当内核空间发生某种事件之后，可以立即通知到用户空间。方便用户做出具体的操作。
八、架构设计模式发展的几个阶段
第一个阶段，是发展初期的传统的架构设计模式
第二阶段，是互联网产品盛行下的架构设计模式
第三个阶段，是基于云计算产品的云计算架构设计模式
第四个阶段，是基于计算的架构设计模式
微服务架构
微服务优点：能够被小团队单独开发；能使用不同的语言开发；是松耦合的；能够即时被要求扩展；每个微服务都有自己的存储能力，可以有自己的数据库。也可以有统一数据库。
微服务架构的缺点：当服务数量增加，管理复杂性增加；跟踪问题难
九、15条普适架构原则
N+1设计 ：开发的系统在发生故障时，至少有一个冗余的实例
回滚设计 ：确保系统可以向后兼容。
禁用设计：可以关闭任何发布功能
监控设计 :在设计阶段就要考虑监控，而不是在部署完成后。
多活数据中心设计
采用成熟的技术
故障隔离 ：避免单一业务占用全部资源。避免业务之间的相互影响 2. 机房隔离避免单点故障
水平扩展：随着业务的发展，当需要扩大平台的服务能力时，不必重构软件系统，通过增加新的设备来满足业务增长的需要。
非核心则购买
使用商品化硬件
快速迭代
异步设计
无状态设计
前瞻性设计
自动化
一个好的设计：
1）解决现有需求和问题
2）把控现实的进度和风险
3）预测和规划未来，不要过度的设计，从迭代中演进和完善。
架构设计需求分析: 主要目的是明确架构要解决当前什么问题， 先调研需求方的诉求。
如何开始设计一个架构：业务->功能->技术实现->架构综览图
业务架构:确定总体架构，核心流程, 是最上层的战略架构. 包括业务规划，业务模块、业务流程，对整个系统的业务进行拆分，对领域模型进行设计，把现实的业务转化成抽象对象。一切系统设计原则都要以解决业务问题为最终目标，脱离实际业务的技术情怀架构往往会给系统带入大坑，任何不基于业务做异想天开的架构都是耍流氓。
应用架构:确定子系统的功能范围和划分解决方案:这里所谓应用就是各个逻辑模块或者子系统。
应用分层有两种方式：
一种是水平分（横向），按照功能处理顺序划分应用，比如把系统分为web前端/中间服务/后台任务，这是面向业务深度的划分。
另一种是垂直分（纵向），按照不同的业务类型划分应用，比如进销存系统可以划分为三个独立的应用，这是面向业务广度的划分。
技术架构: 技术调研, 确定系统核心技术点
比如我们要设计一个微服务的订单系统:
1、业务: 确定业务流程: 确定订单关键功能点和流程
2、应用: 确定订单顶层设计,系统模块,对外暴露哪些接口. 接口协议形式.
3、技术: 确定使用哪些技术点: mysql, mongo,是否考虑分表分库. 使用哪些中间件.
4、数据: 如何设计表结构.
5、详细设计:
存在共性原则：合适原则、简单原则、演化原则
合适原则:合适优于业界领先
简单原则:简单优于复杂
演化原则:演化优于一步到位
所有问题的前提要搞清楚我们今天面临的业务量有多大，增长走势是什么样，而且解决高并发的过程，一定是一个循序渐进逐步的过程。
海恩法则：事故的发生是量的积累的结果。
墨菲定律：任何事情都没有表面看起来那么简单 。
· 所有事情的发展都会比你预计的时间长 。
· 会出错的事总会出错。
· 如果你担心某种情况发生，那么它更有可能发生 。
这就需要我们有技术攻关的能力，对任何现象都要秉着以下原则： 为什么发生？ 发生了怎么应对？ 怎么恢复？ 怎么避免？ 对问题要彻查，不能因为问题的现象不明显而忽略
典型架构分层设计：
接入层：主要流量入口，经过简单
应用层：直接对外提供产品功能，例如网站、API接口等。应用层不包含复杂的业务逻辑，只做呈现和转换。
服务层：根据业务领域每个子域单独一个服务，分而治之。
数据层：数据库和NoSQL，文件存储等。
我们先列出目前我们系统有哪些环节,每个环节是否薄弱. 客户端访问服务器端，经过很多环节，任何环节出问题，都不能访问：
接入层：
1、dns被劫持：域名是否使用https。
2、黑客攻击：是否有弱密，服务器权限，数据库权限
3、ddos攻击：是否有必要使用高防IP接入流量。
4、CC攻击：免费和收费版域名分开，网关是否有限流和防刷措施。
应用层：
1、应用服务器宕机。
2、应用服务bug。
3、第三方服务不可用。
服务层：
1、服务不可用或者出现bug
2、第三方服务不可用。
数据层：
1、数据库服务器磁盘损坏导致数据库不可用等
高可用的数据库架构
高质量的服务管理：
1、规范服务管理：CMDB对项目、服务、服务器进行统一管理。
2、自动化发布：发布不影响用户，完善发布流程，自动化发布，可以及时回滚 。
3、自动化测试： 上线完成后进行全面自动化测试。
4、性能压测：通过对服务压测，了解服务可以承载并发能力，以致可以让运维通过预警进行服务器扩容 。
5、代码控制：测试环境使用测试分支，beta环境发布tag，线上使用该tag发布。
6、发布流程：规范上线发布流程。
7、灰度发布：灰度发布服务 。
8、应急处理机制 。
完善的监控告警机制 ：
1、网络流量监控 。
2、系统监控：服务器资源和网络相关监控（CPU、内存等）
3、日志监控：统一日志收集（各个服务）监控，跟踪(log2) 。
4、应用监控：端口存活、进程占用的资源，应用FGC等情况
5、业务监控 ：服务接口功能逻辑是否正常
6、立体监控 监控数据采集后，除了用作系统性能评估、集群规模伸缩性预测等， 最终目标是还可以根据实时监控数据进行风险预警，并对服务器进行失效转移，自动负载调整，最大化利用集群所有机器的资源。
架构师职责：
1、高可用架构设计：包括业务流程，模块划分组合，框架设计，流程纰漏，最后架构设计，技术实现步骤。 系统性的思考，权衡利弊，综合各种因素，设计出具有前瞻性的架构。
2、和运维协调沟通，提出高效的服务治理解决方案，把控服务质量管理。
3、协调沟通：开发之间沟通，产品之间沟通，市场沟通，运维沟通、沟通后产出图形化文档及设计。
4、规范和统筹：保证系统秩序，统一，规范，稳定，高效运行。
研发职责：
1)、参与架构师的架构师设计，并根据设计实现具体细节。
2)、针对开发功能进行自测，压测。
3)、开发代码，使用工具或组件符合架构师制定规范。 包括代码规范、文档规范。
4)、代码部署符合运维部署规范要求。
十、API网关
API 请求到达网关需要经过严格的身份认证、权限认证，才能到达后端服务。支持算法签名，支持 SSL 加密。
可控制单位时间内 API 允许被调用次数。
API网关是一个服务器，是系统的唯一入口。从面向对象设计的角度看，它与外观模式类似。API网关封装了系统内部架构，为每个客户端提供一个定制的API。它可能还具有其它职责，如身份验证、监控、负载均衡、缓存、请求分片与管理、静态响应处理。
十一、架构师的12项修炼
1、变得文雅而又专业的途径：
1）注重关系甚于争执谁对谁错（关系决定一切，它决定哪些项目或工作可以进行，也决定人们为你最高优先的项目工作）；
2）学会委派（允许别人参与解决某个问题）
3）认识到生活是有反射性的（对待生活要积极）
4）有效沟通之生和死（发表和听取有正面影响的话语）
5）正直诚实而不是率直（以不得罪人的方式表达你的意思）
6）不要掩盖问题
7）提供专业的服务
8）忘掉以前的冒犯
2、沟通的原则
1）先听后说
2）专心致志
3）正面思考
4）尽早道歉（对他人做的某个事情不合适或不正确，放下自尊给受影响的人道个歉）
5）不要在缺陷上招致恼羞成怒
2.2、沟通策略
1）多说是，少说不是
2）倾听建议改善合作
3）了解别人和自己的沟通需求
3、协商的原则
1)不要让人惊讶
2）不要模棱两可
3）委派权威而不是义务（不管你委派的人做的决定由什么后果，你仍然要对这些后果负责）
4）有困难时寻求帮助
5）不要掩盖问题
6）即时很难，也要坚持做正确的事情
3.2协商策略
1）倾听内心的呼唤
2）设法同意
3）不要找分歧
4）寻找共同点
5）如果无法一致，就让所有人稍微不满吧
6）将协商作为一种改进措施
