微服务数据库知识框架学习笔记

将大的系统分解，构建逻辑上独立的小系统。每个微服务都有自己的业务逻辑和数据库，对一个微服务的修改不会影响其他微服务。微服务间通信使用轻量级 的协议，如：http、REST、消息协议。

定义

功能完整性，职责单一性原则

围绕业务构建微服务。从技术上来说，微服务不能局限于某个技术栈或者后端存储，可以非常灵活，以便于解决业务问题

让开发参与到软件的运维中，更好的理解自己的软件是如何被使用的。

谁构建，谁负责

微服务必须是独立可部署的，应该可以打包所有依赖，甚至运行环境

基础设施的自动化

开发前就要考虑好，微服务失败对于整个用户体验的影响

能够快速检测到失败，如果可能，自动恢复

微服务对实时监控投入更多的注意力，检测系统指标和业务指标

设计考虑失败

当演进到一定阶段，对微服务的开发，部署，测试，运维等成本都比较低时，就是一个好的微服务

模块分解是否合理的一个关键指标是：是否模块可以独立替换或者更新，而不影响使用者

迭代演进，并非一蹴而就

AP版本兼容性优先考虑

原则

为每个微服务选择最适合的架构和技术，更新架构和技术也更容易

降低企业创新的成本

可以有选择的做扩展

微服务是个有机体，可以自由增加功能，最小化对现有功能的影响

微服务打包了运行环境，使得多版本并存成为可能

围绕微服务构建小的、专注的，敏捷开发团队

优点

横向拆分。按照不同的业务域进行拆分，例如：订单，商品，库存

纵向拆分。把一个业务功能中的不同模块与组件迸行拆分。例如：把公共组件拆分成原子服务，下沉到底层，形成独立的原子服务层。

对业务进行拆分

梳理和抽取核心应用，公共应用，作为独立的服务下沉到核心和公共能力层，逐渐形成稳定的服务中心，使得前端应用更快的响应市场需求

做好微服务的分层

服务的自动注册和发现

接口先行，语言中立

实践

服务越来越多，服务URL配置管理越来越复

解决的问题

服务的注册和发现

硬件负载均衡器的压力越来越大

较复杂均衡和容错

服务间依赖关系变得错踪复杂，甚至分不清哪个应用要在哪个应用之前启动，架构师都不能完整的描述应用的架构关系

对应用分层，比如：核心数据层，业务应用层，不允许低层向高层依赖，以免出现循环依赖

在注册中心定义架构体系，列明有哪些层的定义，每个服务暴露和引用时，都必须声明自己属于哪一层，这样注册中心更容易发现架构的腐化现象

解决的办法

服务的依赖关系

服务多了，沟通成本上升，调某个服务失败找谁，服务的参数有什么约定

服务的负责人和文档

慢慢地—些敏感数据也开始服努化了，安全问题开始变的重要，谁能调用服务，怎么授权

服务需要一个密码，访问带着密码。服务提供者生成令牌，将令牌告诉注册中心，由注册中心决定是否告知消费者。这样就能在注册中心做比较复杂的授权功能

安全问题

避免一个消费者将整个服务给拖垮

服务提供者监测到流量超标时，拒绝部分请求，进行自我保护

流量控制

保证重要应用的服务质量

应用分离

读写分离

路由

所以线上需要有一个自动运行的验证程序，用户只需在界面上填上要验证的服务方法，以及参数值和期望的返回值，当有一个服务提供者上线时，将自动运行 该用例，并将运行结果发邮件通知负责人

自动测试

本地短路策略。优先凋用JVM内服务提供者，其次是同一台主机上的，最后是跨网络调用

服务路由

因为暴露服务很简单，服务的上线越来越随意，有时候负责服务化的架构师都不知道有人上线了某个服务，使得线上服务鱼龙混杂，甚至出现重复的服务很务下线比上线还困难

需要一个新服务上线审批流程，必须经过服务化的架构师审批过了，才可以上线。而服务下线时，应先标识为过时，然后通知调用方尽快修改调用，直到没有人调此服务，才能下线。

上线审批，下线通知

因服务接口设计的经验一直在慢慢的积累过程中，很多接口并不能促而蹴，在修改的过程中，如何保证兼容性，怎么判断是否兼容?另外，更深层次的业务行为兼容吗?

可以根据使用的协议类型，分析接口及领域模型的变更是否兼容，比如：对比加减字段，方法签名等。而业务上，可能需要基于自动回归测试用例，形成 Technology Compatibility Kit (TCK），确保兼容升级

兼容性

随着服务的不停升级，总有些意想不到的事情产生，比如 Cache写错了导致内存溢出，每次核心服务一挂，影响一大片，人心惶惶

应用间声明依赖强度，哪些功能是强依赖，哪些事弱依赖，基于依赖强度计算影响面，定期测试复查，，加强关键路径上服务的优化和容错，清理不该存在在关键路径上的服务

提供容错的Mc数据，Mock数据可以在注册中心动态下发，当服务不可用时，使用Mck数据

前端页面的 Porta也应该应用降级，当 Porta获取不到数据时，直接隐藏，或者替换成其他模块展示，并提供开关，可人工干预是否显示

容错和降级

当已经有很多小服务，可能需要组合多个小服务的大服务，为此不得不包装一个新服务，新服务业务逻辑少，却带来很大的开发工作量

需要一个服务编排引擎，内置简单的流程引孳，只需要用XML或者DSL声明如何聚合服务，注册中心可以直接下发给消费者执行聚合逻辑，或者部署通用的编排服务器 求由编排服务器转发

服务的编排

并不是所有服务的访问量都大，很多的服务都只有一丁点访问量，却需要部两台提供服务的机器，进行HA互备，如何减少浪的机器

机器总是的闲时和忙时，或者冗余机器防灾，如何提高机器的利用率?

此时可能需要让服务容器支持在一台机器上部署多个应用，可以用多JVM隔离，也可以用 Classloader隔离。

即然已经可以自动部醫了，那根据监控数据，就可以实现资源凋度，根据应用的压力情况，自动添加机器并部署。

服务资源调度

服务调用量越来越大，服务的容量问题就暴出来了，这个服务需要多少机器支，什么时候该加机器

第一步，将每天的调用量和响应时间统计出来，作为容量规划的参考指标

要动态可以调鉴权重，在线上将某一台机器的权重一直加大，直到达到响应时间的阈值 时的访问量，再用访问量乘以机器数反推总容量

容量规划

治理策略

微服务数据库知识框架学习笔记