微服务架构实践
本文转载于本人的微信公众号中的文章，最新文章请关注公众号。html
目录前端
业务背景
微服务概念
微服务技术选型
微服务架构设计
微服务架构设计落地
微服务架构设计过程当中积累的心得
总结数据库
1、业务背景
1.1 产品现状
一、各产品系统独立开发，代码复用率低，系统之间互相调用，耦合严重，系统解耦独立部署困难。
二、传统的单体架构，规模愈来愈大也愈来愈笨重；当新功能的开发、功能的重构变得再也不敏捷可控；测试者的回归测试边界难以琢磨；系统的上线部署也变的艰难
三、高并发访问下没法提供可靠性服务
四、持续集成、持续部署、持续交付等工程效率化工具严重缺失
五、监控系统、日志分析等系统稳定性工具严重缺失
以上种种状况，都让咱们应对需求的变化而变得迟钝。后端
1.2 业务需求
架构确定是为业务需求而生的，先来看看咱们面对的业务需求及其特色。平台最主要知足两大类业务需求：面向餐饮企业在餐饮新零售下的经营和运营需求和面向产品及运营团队。
具体来看：
一、餐饮新零售下的餐饮企业经营和运营的痛点缓存
-
如何提高营销能力和管理会员，以更低的成本为餐饮企业带来更多利润安全
-
如何对数据进行深度挖掘和分析，助力决策者进行运营决策服务器
-
如何掌握实时数据，让决策者及时了解餐厅运营状况微信
二、面向产品及运营团队网络
-
主要是提高产品控制能力，促进总体系统的良好运转前端工程师
所以开发SAAS服务的产品迫在眉睫，须要知足快速开发、灵活升级、高性能、高可用、高稳定、简化运维等更高的需求。
这一步的转型，不是"快"与"慢"，而是"生"与"死"。
2、微服务概念
专一于单一责任与功能独立运行的服务，模组化方式组合出大型应用。
2.1 特色
-
集中式架构：单体无分散
-
分布式架构：分散压力
-
微服务架构：分散能力
2.2 微服务架构优点
-
每一个微服务组件都是简单灵活的，可以独立部署。再也不像单体应用时代，应用须要一个庞大的应用服务器来支撑。
-
能够由一个小团队负责更专一专业，相应的也就更高效可靠。
-
微服务之间是松耦合的，微服务内部是高内聚的，每一个微服务很容易按需扩展。
3、微服务技术选型和微服务的问题
3.1 技术选型
3.1.1 技术矩阵结论
-
Netflix提供了比较全面的解决方案
-
Spring Cloud对于Netflix的封装比较全面
-
Spring Cloud基于Spring Boot，团队有基础
-
Spring Cloud提供了Control Bus可以帮助实现监控埋点
-
业务应用部署在阿里云，Spring Cloud对12 Factors以及Cloud-Native的支持，有利于在云环境下使用
3.1.2 团队指望
-
首先支持Rest
-
团队技术栈和实例比较单薄，但愿对新的技术平滑的学习曲线和可以Hold住
-
小团队，但愿可以有一个比较全面的解决方案
-
目前团队主要采用Spring Cloud + Spring Boot的方式实现服务化
有关技术选型详细分析，请查看个人上一篇文章《个人技术选型》。
3.2 微服务带来的问题
-
依赖服务变动很难跟踪，其余团队的服务接口文档过时怎么办？依赖的服务没有准备好，如何验证我开发的功能。
-
部分模块重复构建，跨团队、跨系统、跨语言会有不少的重复建设。
-
微服务放大了分布式架构的系列问题，如分布式事务怎么处理？依赖服务不稳定怎么办？
-
运维复杂度陡增，如：部署物数量多、监控进程多致使总体运维复杂度提高。
上面这些问题咱们应该都遇到过，而且总结造成了本身的一些解决方案，好比提供文档管理、服务治理、服务模拟的工具和框架； 实现统一认证、统一配置、统一日志框架、分布式汇总分析； 采用全局事务方案、采用异步模拟同步；搭建持续集成平台、统一监控平台等等。
微服务架构是一把双刃剑，虽然解决了集中式架构和分布式架构的问题，却带来了如上种种问题。所以咱们是须要一个微服务应用平台才能总体性的解决这些问题。
4、微服务架构设计
4.1 微服务应用架构设计原则
4.2 微服务应用架构设计目标
微服务架构设计的目标，知足快速开发、灵活升级、高性能、高可用、高稳定、简化运维等更高的需求。
4.3 微服务应用整体架构
微服务应用平台的整体架构，主要是从开发集成、微服务运行容器与平台、运行时监控治理和外部渠道接入等维度来划分和考虑的。
-
开发集成：主要是搭建一个微服务平台须要具有的一些工具和仓库
-
运行时：要有微服务平台来提供一些基础能力和分布式的支撑能力，咱们的微服务运行容器则会运行在这个平台之上。
-
监控治理：则是致力于在运行时可以对受管的微服务进行统一的监控、配置等能力。
-
服务网关： 则是负责与前端的WEB应用 移动APP 等渠道集成，对前端请求进行认证鉴权，而后路由转发。
4.4 微服务框架概览
这里不详细讲解服务框架中每个组件，另开一篇文章来说解。
5、微服务架构设计落地
5.1 基础环境
一个企业的IT建设很是重要的三大基础环境：团队协做环境、服务基础环境、IT基础设施。
-
团队协做环境：主要是DevOps领域的范畴，负责从需求到计划任务，团队协做，再到质量管理、持续集成和发布。
-
服务基础环境：指的是微服务应用平台，其目标主要就是要支撑微服务应用的设计开发测试，运行期的业务数据处理和应用的管理监控。
-
IT基础设施：主要是各类运行环境支撑如IaaS (VM虚拟化)和CaaS (容器虚拟化)等实现方式。
5.2 服务通讯
服务间的通讯，每每采用HTTP+REST 和 RPC通讯协议。
HTTP+REST，对服务约束彻底靠提供者的自觉。
-
特色是简单，对开发使用友好。
-
缺点治理起来困难，链接的无状态，缺失多路复用、服务端推送等。
RPC对通讯双方定义了数据约束。
-
链接大多基于长链接以得到性能的提高及附带的服务端推、调用链路监控埋点等，加强了系统的附加能力。
-
缺点是对调用端提出了新的要求。
综合来看，RPC从性能、契约优先来讲具备优点，如何作到扬长避短呢？
引入GateWay层，让REST与RPC的优势进行融合，在GateWay层提供REST的接入能力。
5.3 服务注册/发现
之前的单体应用之间互相调用时配置个IP或域名就好了，但在微服务架构下，服务提供者会有不少，手工配置IP地址或域名又变成了一个耦合和繁琐的事情。那么服务自动注册发现的方案就解决了这个问题。
咱们的服务注册发现能力是依赖SpringCloud Eureka组件实现的。服务在启动的时候，会将本身要发布的服务注册到服务注册中心；运行时，若是须要调用其余微服务的接口，那么就要先到注册中心获取服务提供者的地址，拿到地址后，经过微服务容器内部的简单负载均衡期进行路由用。
Eureka Server特色：
-
Eureka Client会缓存服务注册信息
-
Eureka Server的注册信息只存储在内存中
-
Eureka的注册只针对application级别，不支持更细粒度的服务注册，如单个服务Rest
-
服务每隔30秒向Eureka Server发送心跳，不建议修改心跳时间。Eureka用这个时间来判断集群内是否存在大范围的服务通讯异常
-
若是在15分钟内有85%的服务没有被续约，则Eureka Server中止移除已注册的服务，以保障已注册的服务信息不丢失
-
Eureka Server之间的数据同步，采用全量拉取，增量同步的方式
-
Eureka 知足分布式事务中的CAP理论中的AP
5.4 集中式配置管理
微服务分布式环境下，一个系统拆分为不少个微服务，必定要告别运维手工修改配置配置的方式。须要采用集中配置管理的方式来提高运维的效率。配置文件主要有运行前的静态配置和运行期的动态配置两种。
-
静态配置一般是在编译部署包以前设置好。
-
动态配置则是系统运行过程当中须要调整的系统变量或者业务参数。
要想作到集中的配置管理，那么须要注意如下几点。
-
配置与介质分离，这个就须要经过制定规范的方式来控制。
-
配置的方式要统一，格式、读写方式、变动热更新的模式尽可能统一，要采用统一的配置框架。
-
须要运行时须要有个配置中心来统一管理业务系统中的配置信息。
概念抽象：
介质，是源码编译后的产物与环境无关，多环境下应该是能够共用的如：jar
5.5 统一认证鉴权
安全认证方面，咱们基于Spring Security OAuth2 + JWT作安全令牌，实现统一的安全认证与鉴权，使得微服务之间可以按需隔离和安全互通。
认证鉴权必定是个公共的服务，而不是多个系统各自建设。
5.6 分布式调用
微服务架构下，相对于传统部署方式，存在更多的分布式调用，那么“如何在不肯定的环境中交付肯定的服务”，这句话能够简单理解为，我所依赖的服务的可靠性是没法保证的状况下，我如何保证本身可以正常的提供服务，不被我依赖的其余服务拖垮？
咱们采用的方案：
-
合理的超时时间
-
合理的重试机制
-
合理的异步机制
-
合理的限流机制（调用次数和频率）
-
合理的降级机制
-
合理的熔断机制
推荐SEDA架构来解决这个问题。
SEDA : staged event-driven architecture本质上就是采用分布式事件驱动的模式，用异步模拟来同步，无阻塞等待，再加上资源分配隔离结起来的一个解决方案。
5.7 分布式事务
分布式事务-CAP
-
C 分布式环境下多个节点的数据是否强一致
-
A 分布式服务能一直保证可用状态
-
P 网络分区的容错性
分布式事务-策略
-
避免跨库事务，尽量相关表在同一个DB
-
2PC 3PC TCC 补偿模式等， 耗时且复杂
-
基于MQ的最终一致性 简单、高效、易于理解
-
将远程分布式事务拆解成一系列本地的事务
分布式事务-基于MQ
5.8 服务拆分
服务拆分方式
AKF扩展立方体，是抽象总结的应用扩展的三个维度。
-
X轴 扩展部署实例，就是讲单体系统多运行几个实例，作个集群加负载均衡的模式。
-
Y轴 业务领域分离，就是基于不一样的业务拆分。
-
Z轴 数据隔离分区，好比共享单车在用户量激增时，集群模式撑不住了，那就按照用户请求的地区进行数据分区，北京、上海、深圳等多建几个集群。
服务拆分要点
-
低耦合、高内聚：一个服务完成一个独立的功能
-
按照团队结构：小规模团队维护，快速迭代
5.9 数据库拆分
单库单表难以支撑日益增加的业务量和数据量，服务拆分了数据库也跟着拆分。
5.9.1 模式
-
垂直拆分
-
水平拆分
5.9.2 原则
-
尽量不拆分
-
避免跨库事务
-
单表量级1000w
-
避免垮裤join（冗余、全局表）
5.10 日志管理
日志主要有三种，系统日志，业务日志，跟踪日志。有了这些日志，在出问题的时候可以帮助咱们获取一些关键信息进行问题定位。
要想作到，出了问题可以追根溯源，那么咱们须要一个能够将整个完整的请求调用链串联起来的标识，这个标识可以让咱们快速定位问题发生的具体时间地点以及相关信息，可以快速还原业务交易全链路。对这些日志与流水的细节处理，对于系统运维问题定位有很是大的帮助。一般开源框架只是提供基础的框架，而设计一个平台则必定要考虑直接提供统一规范的基础能力。
分布式跟踪
5.11 服务契约与API管理
对于前面提到的微服务带来的依赖管理问题，咱们须要提供API管理能力。说到API管理，那首先就用提到服务契约。
服务契约，主要描述服务接口的输入输出规格标准和其余一些服务调用集成相关的规格内容。
5.12 服务契约与服务模拟
有了服务契约，研发人员就能够方便的获取到依赖服务变动的状况，可以及时的根据依赖服务的变化调整本身的程序，而且可以方便的进行模拟测试验证。
根据契约生成模拟服务也就是咱们常说的服务挡板，这样即便依赖的其余服务还没法提供功能，咱们也能够经过挡板来进行联调测试。
5.13 微服务容器
咱们要作稳定、高效、易扩展的微服务应用，实际上咱们须要作的事情仍是很是多的。若是没有一个统一的微服务容器，这些能力在每一个微服务组件中都须要建设一遍，也很难集成到一块儿。有了统一的微服务运行容器和一些公共的基础服务，前面所提到的微服务架构下部分组件重复建设的问题也迎刃而解。
5.14 持续集成与持续部署
在运维方面，首先咱们要解决的就是持续集成和持续交付，可以方便的用持续集成环境把程序编译成介质包和部署包并持续稳定的部署到每一个环境。
概念抽象：
介质：是源码编译后的产物与环境无关，多环境下应该是能够共用的。如：jar
配置：则是环境相关的信息。
部署包=配置+介质。
5.15 微服务平台与容器云、DevOps的关系
就微服务应用平台自己来讲，并不依赖DevOps和容器云，开发好的部署包能够运行在物理机、虚拟机或者是容器中。然而当微服务应用平台结合了DevOps和容器云以后，咱们就会发现，持续集成和交付变成了一个很是简单便捷而且又可靠的过程。简单几步操做，整套开发、测试、预发或者生产环境就可以搭建完成。
整个过程的复杂度都由平台给屏蔽掉了，经过三大基础环境的整合，咱们可以使分散的微服务组件更简单方便的进行统一管理和运维交付。
5.16 技术团队的组织
技术团队组织 – 小团队
根据“康威定律”，软件架构是由组织的架构决定的，所以按照贝索斯“two-pizza”团队的理论和敏捷方法，构建小的团队，能够有效减小沟通成本，有利于团队的自治。
咱们经过让一个小的团队有比较全面的建制，Leader（熟悉业务和技术）+ 前端工程师 + 后端工程师，每每能够可以比较独立地承接一个或者几个业务的工做。这样团队成员总体负责一个或者几个业务模块，能够极大地提升团队成员的参与感、使命感和责任感，团队成员相互帮助，高度自治，你们要么一块儿成功，要么一块儿失败。
技术团队组织 – 团队划分
团队的划分，是按照业务线划分的。随着业务的复杂度的增长，能够按照业务/子业务线的方式来划分团队，但并非绝对的扁平化，而是严格遵循two-pizza原则。
业务线的划分经常按业务细分，技术团队要负责支持所有业务线，所以技术团队的划分一般按系统或者是业务，Two pizza团队的原则在组织层级的任何部分都适用，当人数过多时，必须继续拆分。
技术团队组织 – 团队合做
技术团队组织 – 结果导向
-
主人翁意识（Ownership）
-
行动力（Bias for Action）
-
吃本身的狗粮（Eat your dog food）
• 工程师负责从需求调研、设计、开发、测试、部署、维护、监控、功能升级等一系列的工做，也就是说软件工程师负责应用或者服务的全生命周期的全部工做
• 运维是团队成员的第一要务，在强大的自动化运维工具的支撑下，软件工程师必须负责服务或者应用的SLA -
开发人员参与架构设计，而不是架构师参与开发
• 研发人员是Owner，对业务和团队负责
• 强调抽象和简化，将复杂的问题分解成简单的问题，并有效解决，避免过分设计
• 鼓励用新技术解决问题，但强调掌控力
6、微服务架构设计过程当中积累的心得
-
深刻理解业务
-
设计阶段要追求完美，实践阶段要考虑实际状况做出平衡
-
容错能力
-
监控先行
-
任何上线可回滚
7、总结
微服务架构是技术升级，但更多的是管理模式的升级、思惟方式的转变。
-EOF-