㈠ 架构高可用高并发系统的设计原则
通过学习《亿级流量网站架构核心技术》及《linux就该这么学》学习笔记及自己的感悟：架构设计之高可用高并发系统设计原则，架构设计包括墨菲定律、康威定律和二八定律三大定律，而系统设计包括高并发原则、高可用和业务设计原则等。
架构设计三大定律
墨菲定律 – 任何事没有表面看起来那么简单 – 所有的事都会比预计的时间长 – 可能出错的事情总会出错 – 担心某种事情发生，那么它就更有可能发生
康威定律 – 系统架构师公司组织架构的反映 – 按照业务闭环进行系统拆分/组织架构划分，实现闭环、高内聚、低耦合，减少沟通成本 – 如果沟通出现问题，应该考虑进行系统和组织架构的调整 – 适合时机进行系统拆分，不要一开始就吧系统、服务拆分拆的非常细，虽然闭环，但是每个人维护的系统多，维护成本高 – 微服务架构的理论基础 – 康威定律https://yq.aliyun.com/articles/8611– 每个架构师都应该研究下康威定律http://36kr.com/p/5042735.html
二八定律 – 80%的结果取决于20%的原因
系统设计遵循的原则
1.高并发原则
无状态
无状态应用，便于水平扩展
有状态配置可通过配置中心实现无状态
实践: Disconf、Yaconf、Zookpeer、Consul、Confd、Diamond、Xdiamond等
拆分
系统维度：按照系统功能、业务拆分，如购物车，结算，订单等
功能维度：对系统功能在做细粒度拆分
读写维度：根据读写比例特征拆分；读多，可考虑多级缓存；写多，可考虑分库分表
AOP维度： 根据访问特征，按照AOP进行拆分，比如商品详情页可分为CDN、页面渲染系统，CDN就是一个AOP系统
模块维度：对整体代码结构划分Web、Service、DAO
服务化
服务化演进: 进程内服务-单机远程服务-集群手动注册服务-自动注册和发现服务-服务的分组、隔离、路由-服务治理
考虑服务分组、隔离、限流、黑白名单、超时、重试机制、路由、故障补偿等
实践：利用Nginx、HaProxy、LVS等实现负载均衡，ZooKeeper、Consul等实现自动注册和发现服
消息队列
目的: 服务解耦(一对多消费)、异步处理、流量削峰缓冲等
大流量缓冲： 牺牲强一致性，保证最终一致性(案例：库存扣减，现在Redis中做扣减，记录扣减日志，通过后台进程将扣减日志应用到DB)
数据校对: 解决异步消息机制下消息丢失问题
数据异构
数据异构: 通过消息队列机制接收数据变更，原子化存储
数据闭环: 屏蔽多从数据来源，将数据异构存储，形成闭环
缓存银弹
用户层:
DNS缓存
浏览器DNS缓存
操作系统DNS缓存
本地DNS服务商缓存
DNS服务器缓存
客户端缓存
浏览器缓存(Expires、Cache-Control、Last-Modified、Etag)
App客户缓存(js/css/image…)
代理层：
CDN缓存(一般基于ATS、Varnish、Nginx、Squid等构建,边缘节点-二级节点-中心节点-源站)
接入层：
Opcache： 缓存PHP的Opcodes
Proxy_cache： 代理缓存,可以存储到/dev/shm或者SSD
FastCGI Cache
Nginx+Lua+Redis: 业务数据缓存
Nginx为例：
PHP为例：
应用层：
页面静态化
业务数据缓存(Redis/Memcached/本地文件等)
消息队列
数据层：
Nosql： Redis、Memcache、SSDB等
MySQL： Innodb/MyISAM等Query Cache、Key Cache、Innodb Buffer Size等
系统层：
CPU : L1/L2/L3 Cache/NUMA
内存
磁盘：磁盘本身缓存、dirtyratio/dirtybackground_ratio、阵列卡本身缓存
并发化
2.高可用原则
降级
降级开关集中化管理：将开关配置信息推送到各个应用
可降级的多级读服务：如服务调用降级为只读本地缓存
开关前置化：如Nginx+lua(OpenResty)配置降级策略，引流流量；可基于此做灰度策略
业务降级：高并发下，保证核心功能，次要功能可由同步改为异步策略或屏蔽功能
限流
目的: 防止恶意请求攻击或超出系统峰值
实践：
恶意请求流量只访问到Cache
穿透后端应用的流量使用Nginx的limit处理
恶意IP使用Nginx Deny策略或者iptables拒绝
切流量
目的：屏蔽故障机器
实践:
DNS: 更改域名解析入口，如DNSPOD可以添加备用IP，正常IP故障时，会自主切换到备用地址;生效实践较慢
HttpDNS: 为了绕过运营商LocalDNS实现的精准流量调度
LVS/HaProxy/Nginx: 摘除故障节点
可回滚
发布版本失败时可随时快速回退到上一个稳定版本
3.业务设计原则
防重设计
幂等设计
流程定义
状态与状态机
后台系统操作可反馈
后台系统审批化
文档注释
备份
4.总结
先行规划和设计时有必要的，要对现有问题有方案，对未来有预案;欠下的技术债，迟早都是要还的。
本文作者为网易高级运维工程师
㈡ 微服务架构实践 - 你只懂docker与spring boot就够了吗
背景
随着公司一年多的成长，我们已经开发了数十个项目了，后台有JAVA的有PHP的，为了更好地提升开发与管理效率，各技术大牛小牛们时常进行激烈的PK，碰撞出了许许多多爱的火花，比如其中之一：微服务实践
设计
只需要有一套BASE微服务，BASE微服务生成业务系统微服务实例，供各个业务系统调用；业务系统不直接调用BASE，只能调用微服务INSTANCE。
这是运维的问题，让运维去解决，运维使用工具，实际也不算困难，反正执行的都是脚本，不需要手工操作。
单点故障影响全局，我们选择了稳定更重要；另外saas的话，为了应对不同行业，会存在过度设计的嫌疑；私有化更容易。
调用逻辑
设计理念
非模块化，谈不上微服务，比如我们上面的用户微服务、产品微服务、地址微服务等，都需要先模块化，为了更好地落实开发，你可能不得不，边模块化边微服务，模块化的时候要注意，不能有关联查询，包要完全独立，到时候微服务才能拆开。
松耦合表示我们模块之间不直接依赖，无状态，可以单独地为外界提供服务；
强内聚是指，我们虽然要拆分成一个个小的微服务，但是也要考虑某些功能的强关联性，比如一个凳子是由四个脚与一个板组成，我们不能把四个脚与板分开售卖，就没有意义了。
开发
spring-boot :较springmvc更加简约了，springmvc有一大零的配置文件，比如spring-servlet、spring-mybatis、spring.xml与web.xml，这些在spring-boot都不需要了，只需要强大的注解功能即可，boot更合适微服务。
spring-cloud :里面有比较多组件，用于支持微服务，比如spring cloud config统一配置中心，用于多环境的配置文件配置，大家再也不用为多个微服务的开发、测试与生产环境的配置文件管理而发愁了；spring cloud eureka用于服务注册与发现，下面有单独介绍；其它的组件大家可以去官网看看，这里不一一介绍，总之如果JAVA平台，尽量使用spring体系的内容。
我们采用mysql，因为我们是应用多，但数据量单表并不算大，多则不超过百万，mongodb也实验过，开发非常快，也非常灵活，但因为不是关系型数据库，维护成本较高。
RESTFUL ：URL的资源与操作解耦，让URL更加符合语义，上百个接口也非常好管理，网上有很多文章讲得非常透彻，这玩意不是特别好理解，要多领悟，在项目中实践，就有矛塞盾开的感觉，这里不做详细介绍。
接口文档swagger ：比起传统全手工写接口文档，swagger有统一的输出格式，不管是几个人写的；swagger采用写代码的方式来写接口文档，以前修改了代码，还必须打开wiki手工修改接口文档，现在只需要修改一下代码即可，程序员更愿意修改了，成本更低了，前端与其它调用者不会天天吼着，你这接口咋又变了，新加的字段是啥意思呀。
RocketMQ：一直纠结kafka与rocketMQ，最终选择了RocketMQ
为了性能上面的考虑，尽量使用异步编程，比如注册送优惠券，那么注册成功就可以给用户返回注册成功了，但是送优惠券可以是异步调用的，不阻塞注册的线程。
微服务框架下，日志不可能还分散在各个服务节点上，必须有统一的日志中心。ELK是一个实时日志分析平台，就是将各个服务的日志汇总于日志中心，然后可以按照系统、节点等进行搜索，除上述搜索条件外，我们还在各个微服务实现了按照业务id（一次请求生成一个业务id）与用户id搜索日志，方便跟踪与定位问题。
当然可能有更加轻量级与好用的disconf或spring cloud config，但是我们有php开发的应用，以上二者都不支持。如果全是JAVA应用，采用disconf还是非常不错的。
测试
每个程序员都有这样的经历，刚上线，客户又反馈了bug，原来是我们修改某个功能代码的时候，导致了其它功能的bug，每次上线心里都没底；这就体现了接口测试的必须性，尤其是每次版本升级的时候，都需要执行一遍，以防修改某个接口导致其它接口报错，比手动测试靠谱许多。
部署
docker已经家喻户晓了，这是继虚拟机以后，又一重大变革，将所有的单个微服务都放在docker中，这样你何时何地想部署，直接丢过去就OK了，快到爆。
用几句简单的命令就搞定了负载均衡，而且还可以平滑升级，版本升级的时候，大家就不用告诉客户：系统通知，某日某晚00:00-08:00我行处于系统升级维护中，大家不要去取钱哦，因为你可能取不出来，呵呵。
升级
我们采用工具flyway，可以对数据库脚本进行版本控制。
传统的版本升级，
1.开发推代码并同时记录自己提交了哪些文件；
2.项目经理根据svn审核文件，并打包成war包；
3.投到测试环境让测试公司测试；
4.中途修改了文件，可能需要重新打包；
….
我都写不下去了，项目经理像个超人似的。
现在用持续集成（CI）非常简单，我们用的工具是Jenkins，推完代码，点几下按钮就完成了上线，不管是测试环境，还是生产环境都非常简单，不然项目经理核对文件眼睛都绿了。
结尾
本文主要是介绍微服务开发上的选型，对于细则不做深究，大家感兴趣可以了解下各个组件。当然，我们的选型未免正确，不同场景应用可能完全不同，本文仅供参考。
㈢ disconf-web 可以不配置redis么
disconf-web 可以不配置redis
语句的功能是，若表达式x=y+5大于0则z=x。
下述语句是非法的：
if((x=y+5;)>0) z=x;
因为x=y+5;是语句，不能出现在表达式中。
4.3 数据输入输出的概念及在C语言中的实现
1) 所谓输入输出是以计算机为主体而言的。
2) 本章介绍的是向标准输出设备显示器输出数据的语句。
3) 在C语言中，所有的数据输入／输出都是由库函数完成的。 因此都是函数语句。
4) 在使用C语言库函数时，要用预编译命令
#include
将有关“头文件”包括到源文件中。
㈣ disconf相关问题总结-结合issue，官方文档
对于Web系统：
要实现统一读取，可以使用ThreadContext+AOP来实现。
ThreadContext的使用方式有以下几种：
解决方法一 ：提供ThreadContext包，在每次请求一开始时都复制系统里的所有配置缓存(复制过程要与配置更新Sync互斥)，从而保证每次会话的数据的一致性。
解决方法二 ：提供ThreadContext包，每次请求都绑定一个版本号，如果读取时版本号不一致则报错，需要重新请求。
解决方法三 ：方法二的加强版，添加一个注解定义，标注它是需要强一制性的，每次会话读取时只复制这些强一制性配置(复制过程要与配置更新Sync互斥)。
解决方法四 ：提供ThreadContext包，系统内保存有多个配置缓存层，读取时统一读取某个版本的缓存。每当配置更新时，缓存层增加。
第一种方法，代价太大。第二种方法，严重增加用户负担，第三种还是需要用户关心这个事情。我们将采用 第四种方法 。
对于非Web项目：
比较难解决非一致性读取的问题。因为它没有了会话这样一个概念。Apache的FileChangedReloadingStrategy Reload配置文件的方案也没有解决此问题。所以，我们打算放弃这方面的解决。但是，我们还是会提供一个简单却Ugly的解决方案： 提供函数来标识用户读取配置的边界 。用户可以放弃使用这个方案，但是我们不保证不会发生“不一致读’问题。
服务启动前，zk连接上了：
注意
ZK一般需要以集群的形式提供出来。假设有N台ZK，
** * disconf-client的ZK异常处理
disconf-client可以完全保证: 如果在启动程序时保证ZK集群是可用的 ，那么，就可以保证在任何情况下，与ZK集群的自动连接。
下面按情况进行分析：
程序启动前，zk连接不上
这时disconf-client无法在ZK上注册信息。这是必须禁止发生的情况。也是disconf-client无法支持的情况。
一旦发生这种情况，请先恢复ZK集群，再启动你的程序。
程序启动前，zk连接上了：
如果在程序启动过程中，ZK是正常的，那么，disconf-client可以保证与ZK连接的自动性。
注意
disconf-client必须保证在程序在启动时，ZK集群的可用性。
㈤ disconf zk部署情况为空怎么回事
查看disconf日志，发现zk没有启动。
实际情况是：zk已经启动，可以使用zkServer.sh status命令进行查看。
那么问题就明确了，disconf没有关联上zk。
经过排查，发现在disconf部署目录之下，有一个zk的jar，且版本号和实际使用的版本号不一致。因此，zk才没法连接到disconf，导致最终的zk部署情况为空。
解决办法比较简单：让这个zk的jar和实际使用的zk版本保持一致就OK了。
详细步骤如下：
①在POM.xml中重新改动zk依赖的版本号（改为实际使用的zk版本），重新编译。
②将disconf-web部署目录下的zoo.properties中的hosts改为要启动的zk的client端口号，本机为127.0.0.1:2181。【重要】
经过上述步骤，重新启动zk，发现disconf日志中显示zk已经能够正确连接。
㈥ Spring Cloud全家桶主要组件及简要介绍
一、微服务简介
微服务是最近的一两年的时间里是很火的一个概念。感觉不学习一下都快跟不上时代的步伐了，下边做一下简单的总结和介绍。
何为微服务？简而言之，微服务架构风格这种开发方法，是以开发一组小型服务的方式来开发一个独立的应用系统的。其中每个小型服务都运行在自己的进程中，并经常采用HTTP资源API这样轻量的机制来相互通信。这些服务围绕业务功能进行构建，并能通过全自动的部署机制来进行独立部署。这些微服务可以使用不同的语言来编写，并且可以使用不同的数据存储技术。对这些微服务我们仅做最低限度的集中管理。
一个微服务一般完成某个特定的功能，比如下单管理、客户管理等等。每一个微服务都是微型六角形应用，都有自己的业务逻辑和适配器。一些微服务还会发布API给其它微服务和应用客户端使用。其它微服务完成一个Web UI，运行时，每一个实例可能是一个云VM或者是Docker容器。
比如，一个前面描述系统可能的分解如下：
总的来说，微服务的主旨是将一个原本独立的系统拆分成多个小型服务，这些小型服务都在各自独立的进程中运行，服务之间通过基于HTTP的RESTful API进行通信协作，并且每个服务都维护着自身的数据存储、业务开发、自动化测试以及独立部署机制。
二、微服务的特征
1、每个微服务可独立运行在自己的进程里；
2、一系列独立运行的微服务共同构建起了整个系统；
3、每个服务为独立的业务开发，一个微服务一般完成某个特定的功能，比如：订单管理、用户管理等；
4、微服务之间通过一些轻量的通信机制进行通信，例如通过REST API或者RPC的方式进行调用。
三、微服务的优缺点
1、易于开发和维护
2、启动较快
3、局部修改容易部署
4、技术栈不受限
5、按需伸缩
6、DevOps
四、常见微服务框架
1、服务治理框架
（1）Dubbo、Dubbox（当当网对Dubbo的扩展）
最近的好消息是Dubbo已近重新开始进行运维啦！
（2）Netflix的Eureka、Apache的Consul等。
Spring Cloud Eureka是对Netflix的Eureka的进一步封装。
2、分布式配置管理
（1）网络的Disconf
（2）360的QConf
（3）Spring Cloud组件中的Config
（3）淘宝的Diamond
3、批量任务框架
（1）Spring Cloud组件中的Task
（2）LTS
4、服务追踪框架
。。。
五、Spring Cloud全家桶组件
在介绍Spring Cloud 全家桶之前，首先要介绍一下Netflix ，Netflix 是一个很伟大的公司，在Spring Cloud项目中占着重要的作用，Netflix 公司提供了包括Eureka、Hystrix、Zuul、Archaius等在内的很多组件，在微服务架构中至关重要，Spring在Netflix 的基础上，封装了一系列的组件，命名为：Spring Cloud Eureka、Spring Cloud Hystrix、Spring Cloud Zuul等，下边对各个组件进行分别得介绍：
（1）Spring Cloud Eureka
我们使用微服务，微服务的本质还是各种API接口的调用，那么我们怎么产生这些接口、产生了这些接口之后如何进行调用那？如何进行管理哪？
答案就是Spring Cloud Eureka，我们可以将自己定义的API 接口注册到Spring Cloud Eureka上，Eureka负责服务的注册于发现，如果学习过Zookeeper的话，就可以很好的理解，Eureka的角色和 Zookeeper的角色差不多，都是服务的注册和发现，构成Eureka体系的包括：服务注册中心、服务提供者、服务消费者。
1、两台Eureka服务注册中心构成的服务注册中心的主从复制集群；
2、然后服务提供者向注册中心进行注册、续约、下线服务等；
3、服务消费者向Eureka注册中心拉去服务列表并维护在本地（这也是客户端发现模式的机制体现！）；
4、然后服务消费者根据从Eureka服务注册中心获取的服务列表选取一个服务提供者进行消费服务。
（2）Spring Cloud Ribbon
在上Spring Cloud Eureka描述了服务如何进行注册，注册到哪里，服务消费者如何获取服务生产者的服务信息，但是Eureka只是维护了服务生产者、注册中心、服务消费者三者之间的关系，真正的服务消费者调用服务生产者提供的数据是通过Spring Cloud Ribbon来实现的。
在（1）中提到了服务消费者是将服务从注册中心获取服务生产者的服务列表并维护在本地的，这种客户端发现模式的方式是服务消费者选择合适的节点进行访问服务生产者提供的数据，这种选择合适节点的过程就是Spring Cloud Ribbon完成的。
Spring Cloud Ribbon客户端负载均衡器由此而来。
（3）Spring Cloud Feign
上述（1）、（2）中我们已经使用最简单的方式实现了服务的注册发现和服务的调用操作，如果具体的使用Ribbon调用服务的话，你就可以感受到使用Ribbon的方式还是有一些复杂，因此Spring Cloud Feign应运而生。
简单的可以理解为：Spring Cloud Feign 的出现使得Eureka和Ribbon的使用更为简单。
（4）Spring Cloud Hystrix
我们在（1）、（2）、（3）中知道了使用Eureka进行服务的注册和发现，使用Ribbon实现服务的负载均衡调用，还知道了使用Feign可以简化我们的编码。但是，这些还不足以实现一个高可用的微服务架构。
例如：当有一个服务出现了故障，而服务的调用方不知道服务出现故障，若此时调用放的请求不断的增加，最后就会等待出现故障的依赖方 相应形成任务的积压，最终导致自身服务的瘫痪。
Spring Cloud Hystrix正是为了解决这种情况的，防止对某一故障服务持续进行访问。Hystrix的含义是：断路器，断路器本身是一种开关装置，用于我们家庭的电路保护，防止电流的过载，当线路中有电器发生短路的时候，断路器能够及时切换故障的电器，防止发生过载、发热甚至起火等严重后果。
（5）Spring Cloud Config
对于微服务还不是很多的时候，各种服务的配置管理起来还相对简单，但是当成百上千的微服务节点起来的时候，服务配置的管理变得会复杂起来。
分布式系统中，由于服务数量巨多，为了方便服务配置文件统一管理，实时更新，所以需要分布式配置中心组件。在Spring Cloud中，有分布式配置中心组件Spring Cloud Config ，它支持配置服务放在配置服务的内存中（即本地），也支持放在远程Git仓库中。在Cpring Cloud Config 组件中，分两个角色，一是Config Server，二是Config Client。
Config Server用于配置属性的存储，存储的位置可以为Git仓库、SVN仓库、本地文件等，Config Client用于服务属性的读取。
（6）Spring Cloud Zuul
我们使用Spring Cloud Netflix中的Eureka实现了服务注册中心以及服务注册与发现；而服务间通过Ribbon或Feign实现服务的消费以及均衡负载；通过Spring Cloud Config实现了应用多环境的外部化配置以及版本管理。为了使得服务集群更为健壮，使用Hystrix的融断机制来避免在微服务架构中个别服务出现异常时引起的故障蔓延。
先来说说这样架构需要做的一些事儿以及存在的不足：
1、首先，破坏了服务无状态特点。为了保证对外服务的安全性，我们需要实现对服务访问的权限控制，而开放服务的权限控制机制将会贯穿并污染整个开放服务的业务逻辑，这会带来的最直接问题是，破坏了服务集群中REST API无状态的特点。从具体开发和测试的角度来说，在工作中除了要考虑实际的业务逻辑之外，还需要额外可续对接口访问的控制处理。
2、其次，无法直接复用既有接口。当我们需要对一个即有的集群内访问接口，实现外部服务访问时，我们不得不通过在原有接口上增加校验逻辑，或增加一个代理调用来实现权限控制，无法直接复用原有的接口。
面对类似上面的问题，我们要如何解决呢？下面进入本文的正题：服务网关！
为了解决上面这些问题，我们需要将权限控制这样的东西从我们的服务单元中抽离出去，而最适合这些逻辑的地方就是处于对外访问最前端的地方，我们需要一个更强大一些的均衡负载器，它就是本文将来介绍的：服务网关。
服务网关是微服务架构中一个不可或缺的部分。通过服务网关统一向外系统提供REST API的过程中，除了具备服务路由、均衡负载功能之外，它还具备了权限控制等功能。Spring Cloud Netflix中的Zuul就担任了这样的一个角色，为微服务架构提供了前门保护的作用，同时将权限控制这些较重的非业务逻辑内容迁移到服务路由层面，使得服务集群主体能够具备更高的可复用性和可测试性。
（7）Spring Cloud Bus
在（5）Spring Cloud Config中，我们知道的配置文件可以通过Config Server存储到Git等地方，通过Config Client进行读取，但是我们的配置文件不可能是一直不变的，当我们的配置文件放生变化的时候如何进行更新哪？
一种最简单的方式重新一下Config Client进行重新获取，但Spring Cloud绝对不会让你这样做的，Spring Cloud Bus正是提供一种操作使得我们在不关闭服务的情况下更新我们的配置。
Spring Cloud Bus官方意义：消息总线。
当然动态更新服务配置只是消息总线的一个用处，还有很多其他用处。
六、总结
Spring Cloud 的组件还不止这些，通过上边的口水话的介绍，应该可以大致有一定的了解，但是每一个组件的功能远不止上述介绍的那些，每一个组件还有很多其他的功能点，这里的介绍希望能够带大家入个门，不要对微服务这个这么大的概念有所畏惧。