15.微服务.ppt

* * 案例分析 案例二：如何跨系统访问数据表 案例二：如何跨系统访问数据表 有两个服务，分别是产品目录和财务，左图的场景是财务服务直接调用产品目录的数据表进行数据获取。 这种跨服务的数据获取方式是有问题的，首先无法把控财务服务是如何获取数据的，是否对数据表造成影响，其次从设计的角度来说无疑又增长了系统之间调用的耦合度，系统之间的依赖增强了。 因此演变成右图这样，左图只需提供服务接口给右图调用即可。 案例分析 案例三：服务设计中的不良习惯 案例二：如何跨系统访问数据表 在此系统中，ABCD四个系统进行了串联，这样就要求这四个系统分别都是高可用的，如果其中任何一个系统挂了或者发生问题，都会直接影响其他所有系统。 所以设计微服务架构的时候要尽量避免这种集中式的架构。 如何大规模使用微服务 真正使用微服务，有很多需要关注的点： 1、故障无所不在 网络是不可靠，只能尽力限制引起故障的因数，达到一定规模后，故障不可避免。 2、跨功能需求 服务吞吐量、可用性和数据持久性等这些需求需要持续测量，并保证服务满足可接受的目标。 3、功能降级 构建弹性系统，因微服务功能分散，在有可能down机的微服务上，能够安全的降级以保证弹性 如何大规模使用微服务 4、反服务脆弱 为了不会引起严重级联影响，需要正确的设置超时、实现舱壁隔离或断路层等以避免在第一时间调用一个不健康的服务。 超时 设置超时时间对于调用下游服务十分重要，超时时间设置太长有可能把下游系统拖慢，设置太短可能下游服务未处理完成。最好设置一个默认的超时时间，当超时发生时后，记录到日志里看看发生了什么，并且做响应的调整。 断路器 使用断路器，当请求下游服务发生一定数量的失败后，短路器打开，接下来的请求快速失败。一断时间后，查看下游服务是否已服务，重置断路器。 如何大规模使用微服务 舱壁 为每个下游服务建立单独的连接池。超时和断路器资源受限时释放资源，舱壁第一时间确保它不成为限制。还有一个拒绝请求的舱壁，用以避免资源饱和，称之为减载。 隔离 当下游服务离线，上游服务不受影响。设置成为服务间隔离。 5、幂等 幂等操作，多次执行所产生的影响，均与一次执行影响相同。可以把某些特定业务操作设计成幂等的，比如客户下单送积分。 如何大规模使用微服务 6、扩展 增加负载、减少延迟。 更强大的主机：垂直扩展，更好的机器。 拆分负载：按业务拆分成不同的微服务 分散风险：数据跨机房，异地备份等 负载均衡：避免服务单点故障 作业分离：Job独立服务执行 重新设计：一般设计系统需要考虑10倍容量增长。重新设计系统应对规模化，是成功的标志。 如何大规模使用微服务 7、扩展数据库 服务的可用性 服务的持久性：多副本 读取数据扩展：读写分离 写操作扩展：分表分库 共享数据库设施：容易形成单点故障 CQRS：命令查询职责分离 如何大规模使用微服务 8、缓存的使用 9、自动伸缩 响应型伸缩、预测型伸缩 10、CAP定理 在分布式系统中有三方面需要彼此权衡：一致性、可用性和分区容忍性。这个定理告之我们最多只能能保证三个中的两个。 * * * * * * * * * * * * * * * * * * * * * * 微服务理论与实践 现代互联网的发展方向 当企业发展到一定规模后，一定是大规模、云计算和大数据的三者的结合，从而形成平台，么微服务就是基于此而提出的。 什么是微服务 集中式架构也是单块应用最常使用的架构模式。 分布式架构，最常见的应用是将一个大的任务拆分到不同的机器中进行计算，最终有一台服务器合并计算结果。 第三种就是微服务架构。 什么是微服务 The microservice architectural style is an approach to developing a single application as a suite of small services, each running in its own process and communicating with lightweight mechanisms, often an HTTP resource API. These services are built around business capabilities and independently deployable by fully automated deployment machinery. There is a bare minimum of centralized management of these services , which may be written in different programming languages and use different data