轻量级微服务架构PPT

轻量级·微服务架构方案 (开发篇)汇报人：XXX 汇报时间： 202 X单体应用定义优缺点如何优化如何治本单体应用一、定义单体应用Monolith Application就是将应用程序的所有功能都打包成一个独立的单元。单体应用二、单体应用的优缺点for less-complex systems,the extrabaggoge required to managemicroservices reduces productivityBase Complexitybut rememlhe the seam willd outweigh any monolith/microservice choir优单体应用二、单体应用的优缺点项目交付周期长。0301容易出现系统风险， 一个非主要功能，导致整个系统不可用：随着时间的推移，系统维 护和升级的成本越来越高。缺04相同功能需要重复开发。02性能、稳定性难以优化。05提高部三、如何优化单体应用的开发和运行? 自动化打包、部署、升级和回滚软件系统 代码 开发环境 测试环境 生产环境但是，单体应用的缺点并没有从根本上解决!统性能 使用读写分离、缓存服务监控主机性能、程序性能、并发请求压力、数据库压力自动化发现问题、定位问题和报警监控程序出错位置提前或及时发送警报单体应用 四、如何治本?技术发展日新月异，今天的答案是使用微服务架构。微服务架构定义为什么要使用适合何种系统 缺点平台支撑平台界面微服务架构形像的比喻：微服务架构就像搭 积 木 每个微服务都是一个零 件，并使用这些零件组 装 出不同的形状。一、定义形象比喻一、定义微服务架构通俗解释微服务就是把一个大系统按业务功能分 解成多个小系统，并利用简单的方法使多小系统相互协作， 组 合成一个大系统。微服务架构 一、定义正式解释微服务就是把因 相 同 原 因而变化的功能聚合到一起，而把因 不 同 原 因而变化的功能分离开，并利用轻量化机制(通常为HTTP API)实现通信。微服务不只是一个技术问题，它不仅关系到设计、开发、运维和交付，而且涉及到项目管理及沟通方式的方方面面。促 销商 品通 知订 单结 算新 功 能新 功 能推送支付统计邮件日志短信知识沉淀微服务架构HTTP 调用举个例子发送各种通知认证拉取商品信息获取用户订单业务系统只需关心业务本身一次建设，多系统复用每个模块独立研发，并通过HTTP 接口实现模块间协作扩展新功能，而不影响原有系统微服务架构打消顾虑，微服务架构很简单将大系统分解成小系统，减小系统的复杂性仍然延续现有的技术路线，开发方法上没有变化通过API调用，将多个小系统有机地联系起来仅此而已RESTARESTAAPRPASSONOER8U*0CATeWASWA0ENRESTABRESTAADRVERWANAOENT工RKSMDNTS848584088wfe8?AHMESTDMVRA 网non*cATONmeAAAGCNIg世界十大架构师之 一 的Chris Richardson设计的打车系统微服务架构Eureka Server服务注册/续约 获取服务信息Service ConsumerService Provider远程调用Eureka ClientEureka ClientSpring Cloud组件架构RibbonEurekaServerMobile RegisterHea/th Che-tZuulProxyAdmin(EurekaClient)APPService2MonitorHystrix dashboard,TurbineFein ClienlServicelUser·业务系统微服务架构微服务架构下的迭代交付商品管理订单管理配置系统 单点登录系统 权限管理系统第二周第三周第一周(0开发)微服务架构二、为什么要采用微服务架构?01规避系统性风险避免全局、系统性风险比什么都重要建立自组织型团队，每个小团队围绕明确的工作范围独立并高效地运转(设计、开发、测试、运维)You build it,you run it. -亚马逊CTO Werner Vogels复用微服务组件，避免重复开发。将大型系统分拆成多个可插拔的小系统，独立小团队开发，效率更高。02轻管理03互联网时代什么都得快04降成本05有利于长期发展需求来得快，变化来得快；研发要快，交付要快；系统速度要快，故障恢复要快；什么都得快优化一个大型系统的代价是巨大的，但维护和重构一个微服务是容易的。将大型系统分拆成多个可插拔的小系统，独立小团队开发，更容易响应需求变更。微服务架构三、什么样的系统要采用微服务架构?复杂度高规模大需要长期演进业务复杂人员多代码行数多比如：长期项目、软件产品微服务架构如何利用微服务架构建设系统?先从单个微服务的开发开始微服务架构01开发微服务模块微服务1APIDB微服务2APIDBMGRMGR>原来怎么开发还怎么开发(Java,PHP,.Net,etc.)>每个微服务使用独立的数据库>如果本微服务需要为其它微服务提供接口，建议将API模块和管理端分开来，因为 目的不同API模块的目的是服务于其它模块 管理端的目的是管理本模块的数据 API模块比管理端有更高的性能、稳定性和安全性要求 微服务架构02 API文档管理微服务1MGRAPIDB微服务2MGRAPIDB>文档很重要，因为它是团队协作和知识传递的工具。>文档是程序员永远的痛。 写起来费时费力更新维护时更是费力费神大部分情况下，文档都是过期的将文档放到代码中，与代码一起更新，能够有效地避免以上问题微服务模块AP微 服 务 模 块 A P Iapp-browse-controller:App Browse Controllerapp-cart-controller:App Cart ControllerPOST /cart/check/listGET /cart/check/singlePOT /order/check/listapp-distribute-controller:App Distribute Controller微服务架构03对门户暴露API门户展现层门户后端路由穿透接口 复杂业务接口> 门户前后端分离已是必然的选择>如果门户展现层直接调用微服务的API,将导致微服务模块需要进行用户身份认证和授权的问题>引入门户后端，统一进行用户身份认证和授权>展现层通过门户后端调用微服务API,有两种模式如果微服务的API已经能够很好地满足门户前端的要求，则 通过门户后端的“路由穿透接口”直接穿透到微服务API例如：/router/module1/api_path.json如果微服务的API不能满足门户前端的要求，则需要在门户 后端自定义自己的API,例如查看用户概况功能，就需要在自定义的接口中调用多个微服务的接口。微服务1APIDBMGR微服务2APIMGRDB微服务架构04整合管理端运营管理平台通用权限管理微服务1微服务2微服务3M GRM GRM GR>项目启动时，直接安装通用权限管理模块的程序包(后期会更简单直接选择需要的镜像>微服务开发完成后，在pom .xml中引入通用权限管理模块的客户端即可完成集成工作>经过以上两步，整个管理端即可整合起来。做到按需装卸。公共组件单点登录公 共 组 件小 荷 才 露 尖 尖 角 它日荷花别样红微服务架构门户展现层门户后端路由穿透接口1微服务1API MGRDB单点登录复杂业务接口2