微服务架构原理和设计方法课件(49张).pptVIP

************AKF扩展立方体（参考《TheArtofScalability》），是一个叫AKF的公司的技术专家抽象总结的应用扩展的三个维度。理论上按照这三个扩展模式，可以将一个单体系统，进行无限扩展。?X轴?：指的是水平复制，很好理解，就是讲单体系统多运行几个实例，做个集群加负载均衡的模式。Z轴?：是基于类似的数据分区，比如一个互联网打车应用突然或了，用户量激增，集群模式撑不住了，那就按照用户请求的地区进行数据分区，北京、上海、四川等多建几个集群。

Y轴?：就是我们所说的微服务的拆分模式，就是基于不同的业务拆分。?场景说明：比如打车应用，一个集群撑不住时，分了多个集群，后来用户激增还是不够用，经过分析发现是乘客和车主访问量很大，就将打车应用拆成了三个乘客服务、车主服务、支付服务。三个服务的业务特点各不相同，独立维护，各自都可以再次按需扩展。*前后端分离原则，简单来讲就是前端和后端的代码分离也就是技术上做分离，我们推荐的模式是最好直接采用物理分离的方式部署，进一步促使进行更彻底的分离。不要继续以前的服务端模板技术，比如JSP，把JavaJSHTMLCSS都堆到一个页面里，稍复杂的页面就无法维护。这种分离模式的方式有几个好处：

前后端技术分离，可以由各自的专家来对各自的领域进行优化，这样前端的用户体验优化效果会更好。分离模式下，前后端交互界面更加清晰，就剩下了接口和模型，后端的接口简洁明了，更容易维护。前端多渠道集成场景更容易实现，后端服务无需变更，采用统一的数据和模型，可以支撑前端的webUI\移动App等访问。*对于无状态服务，首先说一下什么是状态：如果一个数据需要被多个服务共享，才能完成一笔交易，那么这个数据被称为状态。进而依赖这个“状态”数据的服务被称为有状态服务，反之称为无状态服务。

那么这个无状态服务原则并不是说在微服务架构里就不允许存在状态，表达的真实意思是要把有状态的业务服务改变为无状态的计算类服务，那么状态数据也就相应的迁移到对应的“有状态数据服务”中。

场景说明：例如我们以前在本地内存中建立的数据缓存、Session缓存，到现在的微服务架构中就应该把这些数据迁移到分布式缓存中存储，让业务服务变成一个无状态的计算节点。迁移后，就可以做到按需动态伸缩，微服务应用在运行时动态增删节点，就不再需要考虑缓存数据如何同步的问题。*无状态协议HTTP，具备先天优势，扩展能力很强。例如需要安全加密是，有现成的成熟方案HTTPS可用。JSON报文序列化，轻量简单，人与机器均可读，学习成本低，有哪些信誉好的足球投注网站引擎友好。语言无关，各大热门语言都提供成熟的RestfulAPI框架，相对其他的一些RPC框架生态更完善。?当然在有些特殊业务场景下，也需要采用其他的RPC框架，如thrift、avro-rpc、grpc。但绝大多数情况下Restful就足够用了。?*****比如提供文档管理、服务治理、服务模拟的工具和框架；实现统一认证、统一配置、统一日志框架、分布式汇总分析；采用全局事务方案、采用异步模拟同步；搭建持续集成平台、统一监控平台等等。*******阿里巴巴公司开源的一个高性能优秀的服务框架，使得应用可通过高性能的RPC实现服务的输出和输入功能，主要核心部件编辑Remoting:?网络通信框架，实现了sync-over-async和Logo?request-response消息机制.RPC:?一个远程过程调用的抽象，支持负载均衡、容灾和集群功能Registry:?服务目录框架用于服务的注册和服务事件发布和订阅*docker***微服务应用设计原则微服务架构原理和设计方法(PPT49页)微服务架构原理和设计方法(PPT49页)微服务应用设计原则微服务架构原理和设计方法(PPT49页)微服务架构原理和设计方法(PPT49页)微服务应用设计原则微服务架构原理和设计方法(PPT49页)微服务架构原理和设计方法(PPT49页)微服务平台-企业IT基础DevOps：负责从需求到计划任务，团队协作，再到质量管理、持续集成和发布。个人基础环境：即微服务应用平台，他的目标主要就是要支撑微服务应用的设计开发测试，运行期的业务数据处理和应用的管理监控。IT基础设施：各种运行环境支撑如IaaS(VM虚拟化)和CaaS(容器虚拟化)等实现方式。微服务架构原理和设计方法(PPT49页)微服务架构原理和设计方法(PPT49页)微服务应用平台目标微服务平台的主要目标主要就是要支撑微服务应用的全生命周期管理，从需求到设计开发测试，运行期的业务数