Week_10 总结
巨无霸系统的痛点
编译部署困难：出了问题重新编译打包时间过长，效率低下，不能适应业务发展需求
代码分支管理困难：代码由团队协作，发布时，各种问题纠缠在一起，merge也困难
数据库连接耗尽：要应对大规模访问，必定是将应用部署在大规模的服务器集群上。每个服务以池化的方式连接数据库，导致数据库资源耗尽
新增业务困难：增加新功能，就需要维护旧功能，逻辑耦合较深，老手忙的要死，新手帮不上忙
怎样解决系统痛点
将系统进行拆分，模块独立部署，降低系统耦合性
纵向拆分
将一个大应用拆分为多个小应用，如果新增业务较为独立，那么就直接将其设计部署为一个独立的Web应用系统。
横向拆分
将复用的业务拆分出来，独立部署为微服务，新增业务只需要调用这些微服务即可快速搭建一个应用系统。
微服务框架
WebService为什么没有发展起来？
现代大型网站需要的是高性能，高可用，易部署，维护方便的系统。在满足业务需求的情况下，简单易用低的维护成本，而webservice不能满足这样的要求，它的确定如下：
臃肿的注册与发现机制
低效的XML 序列化手段
开销相对较高的HTTP 远程通信
复杂的部署与维护手段
微服务框架要有哪些功能？
注册中心：服务的注册与发现
服务提供者：提供服务能力
服务请求者：服务调用方
负载均衡：在服务提供者大规模部署的情况下，需要框架对服务进行负载均衡
失效转移：在服务down机的情况下，框架需要有能力将请求转移到正常的可访问的服务上
高效远程通讯：略
低的应用侵入性：框架需要支持渐进式演化与反复。对应用来说，远程调用与本地调用一样。服务模块既可以集中部署，也可以分布式部署
版本管理：服务接口升级，需要对服务请求者透明，让其不需要感知相关变化。因此接口设计时，需要有版本信息，服务端同时提供多版本支持。访问者客户端升级后，相关历史版本才可关闭
微服务框架（Dubbo）架构
Service Mesh 服务网格
简化客户端的复杂性，将与业务无关的功能进行剥离，进而抽象出service mesh。应用服务只与本地service mesh进行交互。由service mesh进行服务发现，负载均衡以及请求代理等操作。这种方式适用于容器化部署，对应用透明
微服务架构落地
业务先行，先理顺业务边界和依赖，技术是手段而不是目的。
首先需要知道当前业务是什么，问题点在哪，业务依赖有哪些，业务的边界有大。这些心里有谱之后，再通过微服务的手段，将问题解决，限定相应服务范围。用什么方法不重要，重要的是解决现实问题！！！
先有独立的模块，后有分布式的服务。
微服务化的过程是一个渐进的过程，于业务上来说，需要先界定模块，微服务是以模块为基础进行划分的。
业务耦合严重，逻辑复杂多变的系统进行微服务重构要谨慎。
如果是对业务一知半解，或者业务耦合太严重，一时不能快速理清其中条理，此时需要缓缓，用微服务重构更要谨慎，先从边缘功能做起，逐步深入。
要搞清楚实施微服务的目的是什么，业务复用？开发边界清晰？分布式集群提升性能？
实施微服务，重要的是目的。一般来说，有功能复用的目的，也有通过微服务提升开发运维部署等效率问题，还有是通过这种方式提升性能。如果目的并不清晰，或者微服务不能解决问题，那就没必要非上微服务。关键是问题是啥，能不能通过微服务解决，效益在哪。
落地策略
命令与查询职责隔离（CQRS）
接口层面进行读写分离，通过不同微服务，对读写过程进行优化
事件溯源
将用户请求处理过程中的每次状态变化都记录到事件日志中，并按时间序列进行持久化存储。
利用事件溯源，可以精确复现任何用户状态，进行复核审计。
利用事件溯源，可以有效监控用户状态变化，并在此基础上实现分布式事务（服务回滚）。
断路器
为了应对异常放大问题，微服务中使用了断路器机制。当出现故障，错误计数达到阈值时，打开断路器阻断对异常服务的请求。当熔断超时时间到达时，进入半开状态，如果还访问不通，则再次进入打开状态；否则进入断路器关闭状态
服务超时与重试
上游调用者超时时间要大于下游调用者超时时间之和。
微服务架构落地原则
微服务需要格外遵循下列原则：
先确定需求点，到底需要什么，目标是什么
分析达到这样的目标，有什么价值
要实现这样的价值，需要遵循什么原则
基于这些原则，有哪些最佳实践，给予我们参考
根据这些最佳实践，确定有哪些工具可供使用
最后我们使用这些工具，进行了这些实践，达到了我们的目的，实现了相应的价值，满足了我们的需求
还未添加个人签名 2018.09.18 加入
还未添加个人简介
评论