微服务IT架构.pptx

微服务IT架构目 录1微服务架构介绍32Docker技术介绍微服务集成技术微服务的概念单体式架构模式-系统模块化设计，但各模块打包在一起部署。部署简单，但应用逻辑复杂，依赖程度高，开发效率不高，不易扩展，模块间容易互相影响，架构和开发语音调整困难。微服务架构模式-组件、模块每一微服务一般完成某个特定的功能，比如下单管理、客户管理等等。每一个微服务都是微型六角形应用，都有自己的业务逻辑、适配器和数据库。优势解决了系统逻辑过于复杂，便于快速开发，支持服务快速开发独立部署和横向扩展。API GateWay：一些REST API也会向终端和移动互联用户采用的移动应用开放，应用并不直接访问后台服务，而是通过API Gateway来传递中间消息。微服务的优势技术多样性选择-合适的工具和技术干合适的事情具备弹性动态伸缩能力-随需扩展，故障能舱壁实现简化部署，一键部署一键安装一键回退微服务具有可组合简易快速拼装小，简单，容易被替换性，技术无关性微服务是对系统深入了解的情况实现的模块分解与业务支持支持敏捷开发模式，注重开发测试运营的一体化，实现DevOps微小专注DevOps微服务架构和SOA架构的差别比较内容SOA架构微服务架构服务理念面向服务架构思想相同，微服务架构是SOA架构的发展，是面向服务的架构设计，强调服务的松耦合、高内聚和明确的边界划分。服务粒度SOA架构的服务强调系统间的交互需要服务化，服务的粒度相对较粗。微服务架构强调业务系统需要彻底的组件化和服务化，单个业务系统会拆分为多个可以独立开发，设计，运行和运维的小应用。服务粒度注重小而美。暴露组件外功能为微服务。架构风格SOA架构重通道轻终端，一把采用集中式的企业服务总线ESB。微服务轻通道重终端，一般采用去中心分布式系统，但需要具备基本的服务注册，服务代理，服务发布，服务简单的路由，安全访问和授权，服务调用消息和日志记录这些功能还是需要具备如ESC、dubbo等。微服务对外需要暴露集中式API GateWay。云技术应用一般面向传统技术架构。源自互联网，采用云技术，如docker。数据库模式多采用集中式数据库。注重每一个组件有独立数据库。这很难做到！业务敏捷性通过提高服务复用，提升业务敏捷性。更重视敏捷性，重视轻快，持续迭代。强调持续开发集成的开发模式，强调自动化运维和简易横向扩容。服务调用方式支持RPC、RestFul，偏向于使用SOAP等RPC模式，支持同步调用异步调用模式，强调异步调用。支持RPC、RestFul，偏向于采用HTTP API的Rest调用方式，通过Uri表明资源和操作。注重流程编排和事件触发协作。系统访问量大很大微服务的原则微服务是一把双刃剑思考？业务领域掌握的程度决定架构的合理性，错误不可避免。业务模块的分解，模块应该具备独立的数据库，所以数据库的分解和数据的共享整合非常困难，还不足以通用的业务建立准则。数据整合共享需要大数据平台的支撑。管理运行维护、监控、自动化部署的要求很高，需要云技术的支撑。微服务必然面临分布式事务CAP（一致性、可用性、分区容忍性）的问题，AP(牺牲一致性，达到最终一致性）or CP（牺牲可用性）。微服务的架构需要采用循序渐进，快速迭代的方式推进。对于无法很好把控的业务功能或系统可以先集中再逐步微服务化。微服务架构提供一个原则性的方法，原则需要遵守但不可盲目追求原则而完全不考虑实际情况。“规则对于智者来说是指导，对于愚蠢者来说是遵从”目 录1微服务架构介绍32Docker技术介绍微服务相关技术集成技术选型（1/2）保证API的技术无关性，无论采用RPC还是RestFul方式例如使用Java RMI，客户端和服务端必须使用Java语言就存在技术相关性，而采用HTTP+XML或是HTTP+Json则不存在技术相关性。避免破坏性修改，不可避免情况下需要及早发现破坏性的修改如采用SOAP，返回增加一个字段时，客户端可能需要重新编译修改，，而采用普通XML报文，多返回一个字段并不会影响使用。使服务易于服务消费者使用和调度凡是简单，易于使用，快速便捷内容会被留下。便捷简单和耦合度存在关联，需要取舍。如开发统一的API SDK包，SDK应只包含通信安全等代码，不应包含业务逻辑。实现服务的高内聚松耦合，对外屏蔽实现细节例如对数据局库的访问是采用JDBC还是其他，是采用Java语音还是C语音，是采用NIO还是BIO。尽量避免共享数据库，虽然有时候很难做到数据库共享容易导致服务高内聚原则遭受破坏。坚持服务的无状态调用（有些也称为服务即状态）当次服务调用包含了所需的所有信息集成技术选型（2/2）同步 or 异步同步采用请求响应模式，异步基于事件通知和回调机制。编排 or 协同编排（组合调用）：信用卡还款协同（发布订阅）：转账完毕，需要通知短信系统、反洗钱