我只是下了个订单，鬼知道我在微服务里经历了什么

www.icoco.tech/用户在电商网站中购买成…

题目：用户在电商网站中购买成功了，那么它在微服务中经历了什么？

当我傻啊，用户在电商网站购买成功，还在微服务中，那确定就是有一套微服务架构的电商系统。

设计一套电商系统还不简单

简单想象一下，既然是一个电商系统，有用户去购买，就确定得有一个用户模块，购买什么东西总不是西北风吧，购买确定是商品吧，省掉购物车，就得有商品模块吧，商品总得有库存吧，库存就暂时跟商品放一块儿吧，什么仓储物流先别管，就看成是虚拟商品好了，反正题目也没说不能是虚拟商品^_^，购买成功了，那就必须有订单吧，加个订单模块，下完单总得支付吧，不付钱人家凭什么把东西给你，那就得有个支付模块。

简单粗暴，四个模块

用户模块，商品模块（库存），订单模块，支付模块

好，几个模块搞定，外加下单流程图

• 等等，貌似题目说是微服务，既然是微服务就涉及到拆分服务的问题

DDD 领域驱动设计

刚刚确实是梳理了一下模块，既然是微服务，就得进行服务的拆分，服务怎么进行拆分呢，貌似按照刚次梳理模块来划分也是能够，不过这样好像显得我很不是专业，据说如今不少人都要使用DDD（领域驱动设计）来指导微服务的拆分。

参考DDD的设计，DDD官方的架构草图，整体架构分为四层，Infrastructure(基础实施层)，Domain(领域层)，Application(应用层)，Interfaces(表示层，也叫用户界面层或是接口层)

微服务结合DDD

不过对于领域设计而言代码层其实不是最重要，最要的是如何去划分领域，划分好边界。而对于微服务而言，很是适合从业务上去划分各个Modules，划分好各个业务板块，微服务 + DDD，我的以为首先从微服务的角度考虑去划分大的业务模块，每一个微服务都应该是一个能够独立部署，各司其职的模块。简单的说，在微服务实际的开发中，结合DDD的思想去划分全部属于本身的领域。

实施DDD的关键

第一点是使用经过的语言创建全部的聚合，实体，值对象。

第二点也就是最关键的“建模”

• 划分“战略建模”，从一个种宏观的角度去审核整个项目，划分出“界限上下文”，造成具备上帝视角的“上下文映射图”

• 还有一个建模“战术建模”，在咱们的“战略建模”划分出来的“界限上下文”种进行“聚合”，“实体”，“值对象”，并按照模块分组。

构建咱们电商系统的上下文映射图

先来肯定咱们的战略核心的领域是什么，咱们的目的是什么，做为一个电商系统，咱们的核心确定是卖出更多的商品，获取更多订单更多的利润，那么销售能够做为咱们的一个核心的领域。这个做为一个明确核心域确立下来。

肯定完核心子域后，根据对这个领域的理解划分出各个上下文，而后根据上下文再肯定其余的相关领域。

初步咱们能够看出围绕销售核心域的包含的几大块内容，价格，销售方式，购买的方式，已经购买。 而后咱们对支撑着核心域的子域也作了划分，支撑着核心域的有商品域，用户域，通用域有订单域，物流域，支付域。

回到咱们的主题，咱们此次没有购物车，也没有各个会员销售价格，把一些上下文拿掉，并创建映射。

领域驱动设计看似简单，其实很难实施，由于在各个环节中都须要对应的领域专家的参加或指导，这样才能设计出最符合实际的上下文映射图，并且咱们花费的精力可能相比之后的数据驱动开发模式更多，但在总体对项目的把控性能上说，领域比数据驱动更加抽象，更加的顶层设计，在对应互联网的多变状况看得更远。

咱们将微服务拆分为5个领域，分别是销售域，商品域，用户域，订单域，支付域。

完美，接下来就能够开始开发了 ^ _ ^

• 等等，兵马未动，粮草先行；代码未动，图先行，先把时序图画出来

时序图

一个简单的下单流程，涵盖了几个领域

完美，接下来就能够开发微服务了^ _ ^

• 等等，微服务的技术栈还未选型

微服务技术栈选型

服务拆分完了，时序图也画完了，能够开始咱们的微服务之旅了，目前主流的微服务有阿里大名鼎鼎的dubbo和Spring-Cloud全家桶，还有新浪的Motan。比较熟悉的仍是dubbo和spring-cloud，也都使用过，究竟应该选用哪个呢？

由于以前都使用过，作点简单，粗暴的总结。dubbo在很早以前就开始使用，当时的微服务尚未如今这么火，不少理论体系也未完善，dubbo更像是一套rpc整合框架，spring-cloud则更倾向微服务架构的生态。相比Dubbo，springCloud能够说是微服务一整套的解决方案，在功能上是dubbo的一个超级。 Dubbo和SpringCloud比喻，Dubbo架构的微服务就像组装电脑，各个环节自由度很高。springCloud更像品牌机。

基于不折腾，简单快捷，更倾向选择spring-cloud，ok，就定下来技术栈使用spring-cloud，愉快的决定。

• 等等，就这么草率就决定用spring-cloud作为微服务，难道不须要把微服务的利弊先弄清楚吗？

微服务 ： 利和弊

既然选择了微服务，就得知道微服务的利和弊，特别是弊，引入了微服务，就等于引入了一套复杂的体系，一套复杂的体系带来的各类挑战必须事先了解清楚。

利：

1.强模块化边界

咱们知道作软件架构，软件设计，模块化是很是重要的一点，一开始咱们写程序作软件，咱们采用类的方式来作模块化，后面开始采用组件或类库的方式作模块化，能够作到工程上的重用和分享给其余团队来使用。微服务在组件的层次上面又高了一层，以服务的方式来作模块化，每一个团队独立开始和维护本身的服务，有明显的一个边界，开发完一个服务其余团队能够直接调用这个服务，不须要像组件经过jar或源码的方式去进行分享，因此微服务的边界是比较清晰的。

2.可独立部署

3.技术多样性

弊（或者说挑战）：

1.分布式复杂性

在原来单块应用就是一个应用，一个对单块应用的架构比较熟悉的人能够对整个单块应用有一个很好的把控。可是到了分布式系统，微服务化了之后可能涉及到的服务有好几十个，一些大公司可能涉及到的服务上百个，服务与服务之间是经过相互沟通来实现业务，那么这个时候整个系统就变成很是复杂，通常的开发人员或一个团队都没法理解整个系统是如何工做的，这个就是分布式带来的复杂性。

2.最终一致性

微服务的数据是分散式治理的，每一个团队都有本身的数据源和数据拷贝，比方说团队A有订单数据，B团队也有订单数据，团队A修改了订单数据是否应该同步给团队B的数据呢，这里就涉及到数据一致性问题，若是没有很好的解决一致性问题，就可能形成数据的不一致，这个在业务上是不能够接受的。

3.运维复杂性

以往的运维须要管理的是机器+单块的应用，分布式系统和单块应用不同的是，分布式系统须要不少的服务，服务与服务之间相互协同，那么对分布式系统的资源，容量规划，对监控，对整个系统的可靠性稳定性都很是具有挑战的。

只有在清楚了解微服务带来的挑战，明知道山有虎偏向虎山行，才可以真正的胜任挑战，最重要的是，要清楚明了里面有什么坑，这么避免踩坑。

完美，已经了解微服务带来的好处和挑战，接下来就能够开始开发了 ^ _ ^

• 等等，微服务尚未作逻辑分层

微服务怎么作逻辑分层

目前咱们的微服务里面有几个服务，分别是订单，商品，用户，若是客户端向查看 “个人订单” 这么一个接口， 若是客户端假定是pc端，就须要请求三次接口，分别对接订单，商品，用户三个服务，分别拿完三次调用数据，再将三次调用数据进行整合输出展现。要知道pc调用后端服务是走外网，这无疑大大增长了网络的开销，并且让pc端变成更为复杂。假定在中间加多一个层为聚合服务层，即对网络开销进行减小，由于微服务内部是经过内网进行数据传输，也让pc端的业务变得比较简单。

图中的 “pc聚合服务” 也是一个微服务，只不过它是属于聚合服务中间层，咱们将为微服务进行逻辑划分，分为2个层：

微服务基础服务层

基础服务通常属于互联网平台基础性的支撑服务，比方说，电商网站的基础服务有订单服务，商品服务，用户服务等，这些都属于比较基础和原子性，下沉一个公司的基础设施的低层，向下承接存储，向上提供业务能力，有些公司叫（基础服务，中间层服务，公共服务），netflix成为中间层服务。咱们暂且统称为基础服务。

微服务聚合服务层

已经有了基础服务能提供业务能力，为何还须要聚合服务，由于咱们有不一样的接入端，如app和H5，pc等等，它们看似调用大体相同的数据，但其实存在不少差别，例如PC须要展现更多信息，APP须要作信息裁剪等等。通常低层服务都是比较通用的，基础服务应该对外输出相对统一的服务，在抽象上作得比较好。可是对不一样的外界app和pc的接入，咱们须要做出不一样的适配，这个时候须要有一个层去作出聚合裁剪的工做。例如一个商品详情在pc端展现和app端的展现，pc可能会展现更多的信息，而app则须要对信息做出一些裁剪，若是基础服务直接开放接口给到pc和app，那么基础服务也须要去作成各类设配，这个很不利于基础服务的抽象，因此咱们在基础层之上加入聚合服务层，这个层能够针对pc和app作成适当的设配进行相应的裁剪。

那么咱们的微服务中，又增长了一个服务，属于聚合服务。

好了，接下来能够愉快的coding...

• 等等，貌似不对，若是是单块应用加上事务应该没问题，这里是分布式，恐怕得考虑加分布式事务

分布式事务

咱们来理一理建立订单和扣件库存模块之间的关系

能够发现，由于微服务的缘由，咱们把服务进行了分布式，随着各个数据库也随着变成分布式每一个数据库不必定存在相同的物理机中，那么这个时候单个数据库的ACID已经不能适应这种状况，而在这种集群中想去保证集群的ACID几乎很难达到，或者即便能达到那么效率和性能会大幅降低，最为关键的是再很难扩展新的分区了，这个时候若是再追求集群的ACID会致使咱们的系统变得不好，这时咱们就须要引入一个新的理论原则来适应这种集群的状况，就是 CAP

CAP定理

CAP 必须知足一下的3个属性：

• 一致性（C）：在分布式系统中的全部数据备份，在同一时刻是否一样的值。（等同于全部节点访问同一份最新的数据副本）
• 可用性（A）：在集群中一部分节点故障后，集群总体是否还能响应客户端的读写请求。（对数据更新具有高可用性）
• 分区容错性（P）：以实际效果而言，分区至关于对通讯的时限要求。系统若是不能在时限内达成数据一致性，就意味着发生了分区的状况，必须就当前操做在C和A之间作出选择。

简单的来讲，在一个分布式系统中，最多能支持上面的两种属性。但显然既然是分布式注定咱们是必然要进行分区，既然分区，咱们就没法百分百避免分区的错误。所以，咱们只能在一致性和可用性去做出选择。

在分布式系统中，咱们每每追求的是可用性，它的重要性比一致性要高，那么如何实现高可用，这里又有一个理论，就是BASE理论，它给CAP理论作了进一步的扩充。

BASE理论

BASE指出：

• Basically Available（基本可用）
• Soft state（软状态）
• Eventually consistent（最终一致性）

BASE理论是对CAP中的一致性和可用性进行一个权衡的结果，理论的核心思想就是：咱们没法作到强一致，但每一个应用均可以根据自身的业务特色，采用适当的方式来使系统达到最终一致性

好了，说了一大顿理论，程序员们都等急了，赶快来看看分布式事务的解决方案有哪些，能够进行接下去的coding...

来吧，讨论技术方案：

几个方案拿出来了，由于咱们不是专门来说解分布式事务的机制和原理，主要仍是来作分布式事务的技术选型。

先排除掉咱们应该不会选择的方案，一个是XA两阶段提交，这个在不少传统型公司会被使用，但不适合互联网微服务的分布式系统，锁定资源时间长，性能影响大，排除。

另外一个是ali的GTS并无开源，目前已经开源了fescar，不过目前善缺乏调研，可能在下个阶段研究后会使用，目前先排除。

剩下的是TCC和MQ消息事务两种

MQ消息事务-RocketMQ

先说说MQ的分布式事务，RocketMq在4.3版本已经正式宣布支持分布式事务，在选择Rokcetmq作分布式事务请务必选择4.3以上的版本。

事务消息做为一种异步确保型事务， 将两个事务分支经过 MQ 进行异步解耦，RocketMQ 事务消息的设计流程一样借鉴了两阶段提交理论，总体交互流程以下图所示：

这个时候咱们基本能够认为，只有MQ发送方本身的本地事务执行完毕，那么MQ的订阅方一定百分百可以接收到消息，咱们再对下单减库存的步骤进行改造：

这里涉及到一个异步化的改造，咱们理一下若是是同步流程中的各个步骤

1. 查看商品详情（或购物车）
2. 计算商品价格和目前商品存在库存（生成订单详情）
3. 商品扣库存（调用商品库存服务）
4. 订单确认（生成有效订单）

订单建立完成后，发布一个事件“orderCreate” 到消息队列中，而后由MQ转发给订阅该消息的服务，由于是基于消息事务，咱们能够认为订阅该消息的商品模块是百分百能收到这个消息的。

商品服务接受到orderCreate消息后就执行扣减库存的操做，注意⚠️，这里可能会有一些不可抗的因素致使扣减库存失败，不管成功或失败，商品服务都将发送一个扣减库存结果的消息“stroeReduce”到消息队列中，订单服务会订阅扣减库存的结果。

订单服务收到消息后有两种可能：

1. 若是扣减库存成功，将订单状态改成 “确认订单” ，下单成功
2. 若是扣减库存失败，将订单状态改成 “失效订单” ，下单失败

这种模式将确认订单的流程变成异步化，很是适合在高并发的使用，可是，切记了，这个须要前端用户体验的一些改变，要配合产品来涉及流程。

• 完美，使用MQ分布式事务就能够解决调一致性问题

• 等等，MQ消息事务方案的风险了解一下

上面使用MQ的方式确实是能够完成A和B操做，可是A和B并非严格一致性，而是最终一致性，咱们牺牲掉严格一致性，换来性能的提高，这种很适合在大促高并发场景总使用，可是若是B一直执行不成功，那么一致性也会被破坏，后续应该考虑到更多的兜底方案，方案越细系统就将越复杂。

TCC方案

TCC是服务化的二阶段变成模型，每一个业务服务都必须实现 try，confirm，calcel三个方法，这三个方式能够对应到SQL事务中Lock，Commit，Rollback。

1). try阶段 try只是一个初步的操做，进行初步的确认，它的主要职责是完成全部业务的检查，预留业务资源

2). confirm阶段 confirm是在try阶段检查执行完毕后，继续执行的确认操做，必须知足幂等性操做，若是confirm中执行失败，会有事务协调器触发不断的执行，直到知足为止

3). cancel是取消执行，在try没经过并释放掉try阶段预留的资源，也必须知足幂等性，跟confirm同样有可能被不断执行

接下来看看，咱们的下单扣减库存的流程怎么加入TCC

在try的时候，会让库存服务预留n个库存给这个订单使用，让订单服务产生一个“未确认”订单，同时产生这两个预留的资源， 在confirm的时候，会使用在try预留的资源，在TCC事务机制中认为，若是在try阶段能正常预留的资源，那么在confirm必定能完整的提交

在try的时候，有任务一方为执行失败，则会执行cancel的接口操做，将在try阶段预留的资源进行释放。

完美，能够把咱们的系统引入TCC ^ _ ^

• 等等，有同窗提问

• 有同窗可能会问了，若是在confirm或cancel中，有一方的操做失败了，可能出现异常等状况该怎么解决，这个就涉及TCC的事务协调器了，事务协调器就confirm或cancel没有获得返回的时候，会启用定时器不断的进行confirm或cancel的重试，这个也就是咱们强调，confirm，cancel接口必须是幂等性的一个缘由了

• 还有同窗会问了，为何事务协调器知道confirm，或cancel没有完成，这个就涉及到了TCC也作了一张本地消息表，会记录一次事务，包括主事务，子事务，事务的完成状况都会记录在这种表中（固然未必是表，多是zk，redis等等介质），而后启用一个定时器去检查这种表。

• 还有同窗会问，事务怎么传递，这个就涉及使用的TCC的框架了，通常来讲用的都是隐式传参的方式。在主事务建立的时候用隐式传参调用子事务，子事务包含try，confirm，cancel都会记录到事务表里面。

这里推荐TCC的开源框架使用mengyun的TCC，而后也能够其余的，无所谓。

完美，下单的流程开发完毕了，可让QA接入 ^ _ ^

• 等等，微服务的保护措施作了吗

熔断限流隔离降级

微服务分布式依赖关系错综复杂，比方说前端的一个请求，这来到后端会被转为为不少个请求，个时候后台的服务出现不稳定或者延迟，若是没有好的限流熔断措施，可能会形成用户体验的降低，严重的时候会出现雪崩效应，把整个网站给搞垮，若是向阿里巴巴在双11等活动中，若是没有一套好的限流熔断措施，这是不可想象的，多是根本没法支撑那么大的并发容量。

netflix在2012年前也没有设计好的限流容错，当时也是饱受着系统稳定性的困扰，好几回网站由于没有好的熔断措施把网站搞垮，在2012年netflix启动了弹性工程项目，其中有一个产品叫hystrix，这个产品主要用来解决微服务的可靠性，有了这个系统以后，netflix在系统稳定性上上了一个大的台阶，在此以后就没有出现过大规模的雪崩事故

下面使用hystrix也例子来说解一下限流熔断

几个概念：

熔断，隔离，限流，降级，这几个概念是分布式容错最重要的概念和模式。

熔断

若是说房子里面安装了电路熔断器，当你使用超大功率的电路时，有熔断设配帮你保护不至于出问题的时候把问题扩大化。

隔离

咱们知道计算资源都是有限的，cpu，内存，队列，线程池都是资源，他们都是限定的资源数，若是不进行隔离，一个服务的调用可能要消耗不少的线程资源，把其余服务的资源都给占用了，那么可能出现应为一个服务的问题连带效应形成其余服务不能进行访问。

限流

让大流量的访问冲进去咱们的服务时，咱们须要必定的限流措施，比方说咱们规则必定时间内只容许必定的访问数从咱们的资源过，若是再大的化系统会出现问题，那么就须要限流保护。

降级

若是说系统后题没法提供足够的支撑能力，那么须要一个降级能力，保护系统不会被进一步恶化，并且能够对用户提供比较友好的柔性方案，例如告知用户暂时没法访问，请在一段时候后重试等等。

hystrix

hystrix就把上面说的 熔断，隔离，限流，降级封装在这么一个组件里面 下图是hystrix内部设计和调用流程

• 大体的工做流以下：

1. 构建一个HystrixCommand对象，用于封装请求，并在构造方法配置请求被执行须要的参数
2. 执行命令，Hystrix提供了几种执行命令的方法，比较经常使用到的是synchrous和asynchrous
3. 判断电路是否被打开，若是被打开，直接进入fallback方法
4. 判断线程池/队列/信号量是否已经满，若是满了，直接进入fallback方法
5. 执行run方法，通常是HystrixCommand.run()，进入实际的业务调用，执行超时或者执行失败抛出未提早预计的异常时，直接进入fallback方法
6. 不管中间走到哪一步都会进行上报metrics，统计出熔断器的监控指标
7. fallback方法也分实现和备用的环节
8. 最后是返回请求响应

完美，把hystrix加入咱们系统吧，这样忽然有洪峰流量也不至于咱们的系统一下就冲垮 ^ _ ^

• 等等，hystrix的限流数值，错误数熔断，超时熔断，尝试恢复比率这些须要咱们配置的数值应该怎么定呢？

这个就取决你的系统压测的指标和你部署的规模了，这里还涉及到一个容量设计的问题，一会咱们将系统部署上线的时候再来详细说道。

刚刚提到一个问题，就是这些限流数值，错误数熔断这些数字，咱们如今都写在配置文件里面，例如说写在properties，yml里面，当有一天忽然须要把限流数下调（多是系统遭受到什么压力打击），那咱们只能把代码拉下来，巴拉巴拉改了，而后从新上传打包，发布重启，一个流程下来，不说个把小时吧，十来分钟总少不了吧。

想办法咱们把这些配置项放到一个集中式配置中心

集中式配置中心

本身写配种中心还挺麻烦的，去菜市场逛逛吧，菜市场里面有，springcloud-Config，百度的disconf，阿里的diamond，还有携程的apollo

基本上他们的原理都差很少，配置中心能够简单的理解为一个服务模块，开发人员或运维人员能够经过界面对配种中心进行配置，下面相关的微服务链接到配置中心上面就能够实时链接获取到配置中心上面修改的参数。更新的方式通常有两种

• pull模式，服务定时去拉取配置中心的数据
• push模式，服务一直链接到配置中心上，一旦配置有变成，配种中心将把变动的参数推送到对应的微服务上

pull 和 push 两种模式其实各有优缺点。

• pull通常使用定时器拉取，就算某一个网络抖动没有pull成功，在下一次定时器的时候，终将能保证获取最新的配置。

• push能够避免pull定时器存在的延时，基本能够作到实时获取数据，但也有问题就是网络抖动的时候可能会丢失更新。

携程的apollo

携程的apollo比较有特点的是融合了pull和push两种模式，把二者的优势进行告终合，开发或运维人员在配置中心进行修改，配置中心服务将实时将修改推送push到apollo的客户端，但考虑到可能因为某些网络抖动没有推送成功，客户端还具有了定时向apollo服务端拉取pull数据的功能，就算推送没成功，可是只要必定时间周期，客户端仍是会主动去拉取同步数据，保证能把最终配置同步到服务中。这个也是apollo在高可用方面上很是有特点的设计。

apollp在高可用上也作了保证，客户端获取到数据会把数据缓存在内存，还会sync到本地磁盘，就算apollo服务器挂掉了，就算客户端服务重启了，也能够从本地磁盘中拉取回来数据，继续提供对外服务，从这点来看apollo的配置中心在高可用上考虑仍是比较周到的。

把配置中心配置上去后，咱们就能够把hystrix还有mysql的用户密码，还有一些业务开关等等的配置参数放上去了。

完美，开发基本完工了，其实就几个模块，一个简单的下单购物流程，当咱们把系统交付给运维，运维喊道，日志呢，作微服务怎么能够没有调用链日志呢？

调用链监控&日志

确实，微服务是一个分布式很是复杂系统，若是没有一套调用链监控，若是服务之间依赖出现问题就很难进行定位。

下图是ali在鹰眼系统给出的微服务之“熵”

目前个大主流互联网公司中，ali有很是出现的鹰眼系统，点评也有一套很出名的调用链监控系统CAT。调用链监控其实最先是google提出来的，2010年google发表了一篇调用链的论文，论文以它内部的调用链系统dapper命名，这个论文中讲解调用链在google使用的经验和原理，大体的原理以下图：

这里能够采用ELK的方式去记录和展现调用链监控日志，当咱们一条调用为一行记录存储下来

经过traceId 和 parentSpanId 就能够串联起来为一个总体的链路，并能够从这个链路去分析错误或者调用延时和调用次数等等

目前市面主流的调用链选型有 zipkin，pinpoint，cat，skywalking，他们之间各有一些偏重点，值得一说的是skywalking国人出品的一款新的调用链工具，采用开源的基于字节码注入的调用链分析，接入段无代码入侵，并且开源支持多种插件，UI在几款工具来讲比较功能比较强大，并且ui也比较赏心悦目，目前已经加入了apache孵化器。

采用了skywalking做为调用链工具

为什么会采用skywaling，在低层原理的实现，这几款产品都差很少，但在实现和使用的细节相别仍是很大。

• 首先在实现方式上，skywalking基本对于代码作到了无入侵，采用java探针和字节码加强的方式，而在cat还采用了代码埋点，而zipkin采用了拦截请求，pinpoint也是使用java探针和字节码加强。
• 其次在分析的颗粒度上，skywaling是方法级，而zipkin是接口级，其余两款也是方法级。
• 在数据存储上，skywalking能够采用日志体系中比较出名的ES，其余几款，zipkin也可使用ES，pinpoint使用Hbase，cat使用mysql或HDFS，相对复杂，因为目前公司对ES熟悉的人才比较有保证，选择熟悉存储方案也是考虑技术选型的重点。
• 还有就是性能影响，根据网上的一些性能报告，虽然未必百分百准备，但也具有参考价值，skywalking的探针对吞吐量的影响在4者中间是最效的，通过对skywalking的一些压测也大体证实。

完美，把微服务的包打好，上传到服务器就能够运行了 ^ _ ^

• 等等，微服务包都打好了，剩下就是jar包或war包一个一个上传到服务器上，而后用个脚本start，在之前单块应用还好，如今微服务几十几百个应用，请问，运营人员怕不怕？

据说，docker + kubernetes和微服务更配喔

docker + kubernetes

就几个服务，先不用容器化部署了...乍一看，没玩没了，还有CICD，灰度发布...容器编排...

下次再讲把，先把服务部署上去吧

部署到生产，预估容量

该把服务部署上线了，一个服务上线确定得评估下或者预估下访问量有多少用户，有多少访问，这个涉及到该配置多少的机器资源，这应该怎么去估算呢，反正程序员在家里怎么算都算不出来。

评估访问量

1. 问运营，若是是一个已经上线的产品，确定存在已有的用户数和访问数据，就算存在误差，也是可控的范围。
2. 问产品，肯定一个什么样形态的产品，例如是拼团，例如是秒杀，各类处理方式都不一样

评估平均访问量qps

一天86400秒，通常认为请求大部分发生在白天，就按照40000计算，日平均访问量=日总访问量/40000

评估高峰qps

能够把以前每日的访问曲线图拉出来看看，峰值是根据业务不一样而定的，例如，有些业务是白天早上10点的流量偏多，有些业务是晚上人家休闲类的流量偏多，总之，根据业务去估算出日均的峰值，相似于电商类的服务，通常峰值是日均流量的5倍左右。还有例如一些大促活动可能会更高，这个都要跟运营人员提早沟通好的，还有一些活动例如，秒杀，这个就不是靠预估出来，秒杀是另外一种的考虑状况，采起的应对策略跟普通订单是彻底不一样。

评估系统，单机极限qps

在上线以前须要跟测试人员一块儿作压力测试，针对每一个服务每台机器去作，通常来讲，会把一个服务一台机器压到极限，在逐步的进行优化。 思考一个问题，假定单台机器最大的qps是1000，咱们峰值是5000，那须要用多少台机器去抗？答案是大于等于6台，最少的容错不得少于1台。

---

貌似一个很是简单的微服务就差很少，不过貌似仍是差了不少，数一下：

1. 监控系统哪去了：（基础设施监控，系统监控，应用监控，业务监控）
2. 网关哪里去了
3. 统一的异常处理哪里去了
4. API文档哪里去了
5. 容器化哪里去了
6. 服务编排哪里去了
7. ...