基于云原生应用架构设计

一、架构演进

软件开发架构大概分为三个阶段，早期、成长期和稳定期。

第一个阶段为早期单体架构，一般服务端+数据库的方式进行开发，采用三层MVC架构进行开发。主要特点：企业处于早期，业务比较简单，产品功能比较单一，业务会随时根据运营数据进行调整，对开发人员来说，主要讲不同的功能模块进行划分，能够应对业务随时调整的不确定性。

第二阶段成长期，公司公司业务快速成长，DAU可能达到十万，这是时候既要保证业务的稳定运行，又要进行产品的快速迭代。主要特点：前段加速优化，通过CDN等技术让前端的静态资源快速响应客户的操作；水平扩展，让后台服务分布式，需要使用负载均衡实现，但要对负载均衡的分流设计；数据库的优化，主要结构化和非结构数据的设计，以及通过缓存提供数据响应。

第三阶段完全分布式架构。这个主要特点：前端和数据都会很大的压力，对业务响应的效率要求就非常高；弹性扩容，系统因需求和用户的增长，会出现波峰与波谷，需要通过弹性扩容更好利用资源；功能服务化，需要将之前功能服务化，比如：微服务设计；

早期架构

根据早期业务量，我们主要从以下几个方面：技术框架选型、数据存储、缓存选型、静态资源存储。目前来看，前段框架是SpringMVC，也直接采用前后端分离技术，采用SpringBoot+Vue来开发。数据存储一般采用MySQL,缓存采用Redis，静态资源通过Nginx实现本地托管。需要说明就是缓存的设计，基本访问路径是：访问缓存-是否命中-命中直接返回-没有命中-数据库查询-缓存更新。高可用可以通过部署多个节点，当一个节点受到异常的时候，还通过其他节点进行相应，基本可以达到2个9或3个9.

成长期架构

这个阶段对用户需求响应上，比如：全文检索、重大活动支持等。架构设计主要分为以下几块，前端系统扩展、无状态服务设计、在线水平扩展、后端系统扩展、系统通信和消息中间件。

前端资源因为不变主要通过存储分发，主要通过独立域名或CDN技术实现优化；无状态设计。

水平扩展需要条件有：资源快速交付、无状态服务设计、业务性能监控和统一服务入口，实现技术主要是负载均衡，可以采用四层和七层协议分别对不同场景的访问进行转发。

后端系统扩展主要实现缓存服务器和数据库的扩展，缓存服务扩展主要有Twemporxy+Sentinel和Redis Cluster

Redis Cluster采用去中心化设计，每个节点都是平行，通过哈希槽来实现划分，新添加节点时候，使用redis-trib工具将其他几点的slot迁移部分到新节点上面，迁移过程不影响使用。对于数据扩展，前期会通过分库分表来实现，建议分布式库来实现数据库的水平扩展

分布式数据库

系统通信主要根据场景选择通信协议,有http协议、https协议和tcp协议。具体差别不在详述。

消息中间件主要解决应用耦合、异步投递消息、流量削峰，采用RabbitMQ.

这一步可以实现DevOps进一步提高效率，采用的技术方案Jekins+Kubernets。

稳定期架构

稳定期架构主要对系统功能进行拆分，实现服务分而治之、各司其职、协同工作，共同完成业务逻辑。主要几件事：业务拆分、统一配置、分布式任务。

二、应用架构介绍

云原生架构主要对业务场景、隔离故障、容错、自动恢复等非功能性要求考虑较多，通过云原生架构可实现弹性资源的要求、跨机房的高可用、数据高可用（可达99.9999999%）。

云原生架构概念

敏捷基础设施要求像机器等基础资源，能够支持开发人员、运维人员和业务人员通过代码随时拉取、随时释放，同时以接口的方式提供弹性、按需的计算和存储能力，且是自动化。

持续交付要求业务需求变更、迭代和部署是自动化的。

持续交付架构及流程

DevOps(Development and Operation）是开发运维一体化，实际是让开发人员、测试人员和运维人员沟通、协同和整合，要实现整个过程自动化。

微服务主要采用Unxi设计哲学，让每个功能职责单一化，独立化（独立扩展、升级和部署）、服务化，然后通过服务的联合提供整体功能。

架构设计

架构设计主要包含业务拆分、微服务设计、统一配置中心，其中有一块就是分布式任务及一致性设计。

第一业务拆分

拆分的基本原则是“高内聚、低耦合”，拆分的基本方法，首先确定业务边界，主要依据数据独立，但实践过程比较麻烦，有些业务的边界比较模糊，这个时候建议先统一设计，等边界确定后再拆分，不能强制拆分。其次数据库独立，不同业务访问不同的数据库。然后开发的代码独立，开发时候使用独立工程实现其功能。再确定服务之间通信方式，主要同步、异步和同步异步相结合的方式，同步选择目前常用RESTful、分布式服务框架，异步采用消息队列来实现。最后就是服务独立发布与部署。

第二微服务设计

主要包含服务发现、服务治理、框架选择、服务编排和服务测试。

服务发现是动态感知服务访问地址的变化，有服务端发现和客户端发现，区别在于谁负 责维护服务访问地址的变化，服务端发现模式通过DNS或带VIP的负载均衡实现，客户端 主要向注册服务列表选择请求服务，然后直接发起服务请求。一般公有云提供服务端服务 发现机制。技术选型可选择ZooKeeper或Consul中间件来实现。

基于客户端服务发现

服务治理范围涵盖服务的整个生命周期，从服务建模开始、到开发、测试、审批、发布、运行时治理和服务下线，这里主要讨论的服务运行治理，达到在线治理、实时生效。主要两种方式：弹性扩容和熔断机制。弹性扩展介绍基于kubernetes的Horizonal Pod AutoScaler(HPA)弹性扩容机制，实现方法是通过定期轮训Pod的状态，当Pod状态连续达到提前设置的阈值时候，出发副本控制器，修改其应用副本数量，使Pod的负载中心回到正常范围内。熔断机制是对出现故障的节点，当被调用的时候，防止出现级联反应，中断线路，回到初始状态（比如：用户提交订单，调用支付服务的时候，支付服务调用失败，这个时候启动熔断机制，后续用户可以定位页面继续选择支付，否则产生服务调用级联反应）。

熔断机制

微服务框架有SpringCloud和Dubbo,SpringClound是基于SpringBoot，提供一套完整的解决方案，包含功能有分布式配置、服务注册和发现、路由、服务间调用、负载均衡、断路器、选主、集群状态和分布式消息机制，实现通过SpringCloud Config实现统一配置，通过SpringClund Netflix实现服务发现（Eureka）、智能路由（Zuul）、客户负载均衡（Ribbon）。Dubbo是阿里针对大规模网站应用研发微服务架构，主要应用于长链接小数据的模式提供服务，但如果产品业务后台逻辑复杂、时间长而导致异步逻辑比较多的话，可能Dubbo不太合适。具体请参看官方文档。

服务编排以服务为中心定义服务的弹性伸缩、灰度发布、滚动升级、资源配置等功能组合，基于容器的服务编排结合Docker对容器定义进行组合，实现包含对象定义、语法解析、任务调度和模板管理。

微服务测试主要包括单元测试、接口测试、集成测试和系统测试，实现可以通过Mock来实现，Mock通过定义输入和输出，模拟当前服务需要调用其他服务的情况，这样就可以模拟整个流程来对当前上线的服务进行测试。

第三统一配置中心

配置中心主要解决：每个服务都有很多雨来和配置信息，比如：数据库、缓存、队列、运行阈值和策略等等，当业务扩张一定程度后，就需要由一个配置中心，来应对每个业务配置变更。

配置中心工作流程

分布式定时任务

分布式主要包括分布式定时任务、分布式锁等问题，分布式定时任务需要满足分布式、高可用、弹性扩容和统一管理特征，有抢占式和分配式。抢占式是每个Woker定时任务的最终执行者，通过枪战的方式从调度器节点上获取任务，并定时执行，Worker可以连上任意一个调度器节点，申请分配任务。定时任务的调度逻辑放在调度器节点，并最终持续化到任务中心。分配式是调度器只有一个Master节点，Master节点通过分布式锁服务（zk或Redis实现）选取或者竞争产生，Master及诶单任务中心获取定时任务，分配给Worker定时执行。当Master失效是，Slaver节点会重新选举出Master节点。

抢占式调度，优点是实现简单，调度器Master可以水平扩展，缺点是无法控制Worker节点大量并行轮询，可以通过Worker退避轮询或任务中心缓存热点数据等通过方法规避或者部分解决。分配式调度，优点控制任务分配的节点，保证系统的整体负载是正常，缺点是调度器属于一主从模式，需要额外引入分布式锁服务解决Master选取的问题。

可选用的开源框架有:Quartz、Chronos和Scheduled Job，Quartz应用比较广泛，提供多种触发器供使用，当搭建Quartz集群时候，通过悲观锁和标志字段等方式保证一个作业不会被多个Quartz进程调度。Chronos通过Leader和非Leader节点实现分布式调度控制，具备WEBUI、支持ISO8601重复事件表示法、作业精细化等等优势。Scheduled Job是kubernets用于管理事件的作业。

出处：https://www.jianshu.com/p/fe409fb9546e