公司内部的微服务架构培训资料，分为5个部分：1. 重识微服务架构；2. 如何快速体验微服务架构；3. 微服务架构API的开发与治理；4. 微服务架构下的数据一致性；5. 如何用Docker支撑微服务。
消息状态确认 42 消息重发 43 TCC(Try-Confirm-Cancel) 1.1 44 最大努力通知 总结. 49 5如何用 Docker支撑微服务 49 Docker核心概念 镜像(mage) 容器( Container) 镜像仓库( Registry)… 为什么使用 docker实施微服务架构 .52 必须了解的 Docker知识 54 镜像构建 55 容器监控. 60 容器日志 快速运行一个微服务架构Demo 写在最后 62 1重识微服务架构 导语 虽然已经红了很久,但是"微服务架构"正变得越来越重要,也将继续火下去。 各个公司与技术人员都在分享微服务架构的相关知识与实践经验,但我们发 现,目前网上的这些相关文章中,要么上来就是很有借鉴意义的干货,要么就 是以高端的专业术语来讲述何为微服务架构。就是没有一个做到成熟地将技术 传播出来,同时完美地照顾"初入微服务领域人员″,从O开始,采用通俗易懂 的语言去讲解微服务架构的系列 所以,我们邀请青柳云的苏槐与 InfoQ一起共建微服务架构专题"Re:从O 开始的微服务架构″,为还没有入门该领域的技术人员开路,也帮助徴服务架构 老手温故知新。 这是专题的第一篇文章,从最基础的地方入手,让我们重识微服务架构。 前言 得益于2013年 Docker的诞生,微服务概念及架构的推广和落地变得更加 的可靠和方便。在2016年及之前,微服务架构的讨论更多的是活跃于互联网 企业及社区。现如今,随着 Docker和微服务架构组件与 Docker等相关技 术的逐步成熟,微服务架构已然步入传统企业及传统行业。 但是,程序员作为一个理性消费的群体,需要冷静地思考,避免挖个大坑把自 己给埋了。所以,我们需要冷静地搞清楚:微服务(架构)是什么?它有什么 优势劣势?我们为什么需要采用微服务架构?如何让老板接受这一新技术?如 何落地?如何升级维护?等等 我们在过去7年智慧城市的建设过程中,研发和交付了很多的大型项目,踩 过很多的坑,趟过很多的雷,深受传统建设方法之苦,也深深被微服务架构带 来的好处所感动,我们也将在微服务架构这条路的继续前行。在这里,将我们 研发过程中的一些思考和心得分享给大家,供大家参考 也许,在不久的将来,软件开发只需要组装,不再需要从头廾发。 A A Web访问 移动APP 微服务平台 按需装入 微服务 微服务 微服务 微服务 微服务 应用云 商品管 用户中 消息中 订单中 积分中 c(知识/资了变现) (知识/资产变现) 微服务 微服务 微服务 微服务 AP云 位置服 比价服 统计分 财务结 务 务 按需调用 即取即用 基于AP开发 基于业务自定义开发 什么是微服务架构? 形像一点来说,微服务架构就像搭积木,每个微服务都是一个零件,并使用这 些零件组装出不同的形状。通俗来说,微服务架构就是把一个大系统按业务功 能分解成多个职责单一的小系统,并利用简单的方法使多个小系统相互协作, 组合成一个大系统 如果学科派一点,微服务架构就是把因相同原因而变化的功能聚合到一起,而 把因不同原因而变化的功能分离开,并利用轻量化机制(通常为HTTP RESTfuL API)实现通信。 追本溯源, Martin folwer对微服务架构的定乂是: In short, the microservice architectural style [1] 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 Apl. These services are built around business capabllitles 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 storage technologies 微服务架构是一种架构模式,它提倡将单一应用程序划分成一组小的服务,服 务之间互相协调、互相配合,为用户提供最终价值。每个服务运行在其独立的 进程中,服务与服务间采用轻量级的通信机制互相协作(通常是基于HTTP协 议的 RESTfUL API)。每个服务都围绕着具体业务进行构建,并且能够被独立 的部署到生产环境、类生产环境等。另外,对具体的服务而言,应根据业务上 下文,选择合适的语言、工具对其进行构建。(摘自王磊先生的《微服务架构 与实践》) 对于我个人,我更喜欢一种延续性的解释,微服务架构吣模块化开发十分 布式计算。不管微服务架构的定义怎么样,都是在描述一个核心思想:把大系 统拆分成小型系统,把大事化小,以降低系统的复杂性,从而大幅降低系统建 设、升级、运维的风险和成本。 顺带提下,亚马逊创始人Jef仟 F Bezos在2002年就说过:所有团队的模块 都要以 Service lrη terface的方式将数据和功能开放出来。不这样做的人会被 炒鱿鱼。这才是思路超前的大牛。 需要注意的是"微服务"与'微服务架构"是有本质区别的。"微服务"强调的是服 务的大小,它关注的是某一个点。而微服务架构〃则是一种架构思想,需要从 整体上对软件系统进行通盘的考虑 Chris richardson说:"微服务〃是一个很糟糕的名字,它导致开发人员创建 了许多粒度很小的服务,每个服务拥有一个单独的REST端点。不仅如此, 这个名字还喑示了微服务在开发者心目中的重要位置。例如,人们会说我们可 以用微服务来解决这个问题;我也看刭∫越来越多的"某某微服务框架",而实 际上,这些框架跟微服务架构不一定有太多联系,它们只是简单的Web框 架。使用ν微服务架构〃这个名字会更恰当些。它是一种架构风柊,它把一系列 协作的服务组织成一个系统来支撑业务 常见的微服务组件及概念 1.服务注册,服务提供方将自己调用地址注册到服务注册中心,让服务调用方能够方 便地找到自己。 2.服务发现,服务调用方从服务注册中心找到自己需要调用的服务的地址。 3.负载均衡,服务提供方一般以多实例的形式提供服务,负载均衡功能能够让服务调 用方连接到合适的服务节点。并且,节点选择的工作对服务调用方来说是透明的 4.服务网关,服务网关是服务调用的唯一入口,可以在这个组件是实现用户鉴权、动 态路由、灰度发布、AB测试、负载限流等功能。 5.配置中心,将本地化的配置信息( properties,xml,yam等)注册到配置中 心,实现程序包在开发、测试、生产环境的无差别性,方便程序包的迁移。 6.API管理,以方便的形式编写及更新APⅠ文档,并以方便的形式供调用者查看和 测试。 7.集成框架,微服务组件都以职责单一的程序包对外提供服务,集成框架以配置的形 式将所有微服务组件(特别是管理端组件)集成到统一的界面框架下,让用户能够 在统一的界面中使用系统 8.分布式事务,对于重要的业务,需要通过分布式事务技术(TCC、高可用消息服 务、最大努力诵知)保证数据的一致性。 9.调用链,记录完成一个业务逻辑时调用到的微服务,并将这种串行或并行的调用关 系展示出来。在系统出错时,可以方便地找到出错点。 10.支撑平合,系统微服务化后,系统变得更加碎片化,系统的部署、运维、监控等都 比单体架构更加复杂,那么,就需要将大部分的工作自动化。现在,可以通过 Docker等工具来中和这些微服务架构带来的弊端。例如持续集成、蓝绿发布、 健康检查、性能健康等等。严重点,以我们两年的实践经验,可以这么说,如果没 有合适的支撑平台或工具,就不要使用微服务架构。 般情况下,如果希望快速地体会微服务架枃带来的好处,使用 Spring Cloud提供的服务注册( Eureka)、服务发现( Ribbon)、服务网关 (Zuu)三个组件即可以快速入门。其它组件则需要根据自身的业务选择性 使用。 微服务架构有哪些优势劣势? 要诙优势,就一定要有对比,我们可以尝试着从两个维度米对比。 微服务架构与单体架构的对比 S/N对比点 微服务架构 单体架构 结论 1上手难度 AP|接口调用 数据库共享或本地程序调用单体 架构 胜 21开发效率早期设计和沟通的工作量加早期工作量小,随着项目规单体 (简单项大,随着项目规模和时间的推模和时间的推移,效率大幅架构 目) 移,效率变化不大 度下降 胜 22开发效率早期设计和沟通的工作量加早期工作量小,随着项目规微服 (复杂项大,随着项目规模和时间的推模和时间的推移,效率大幅务架 目) 移,效率变化不大 度下降 构胜 3系统设计每个业务单独包装成一个微服以包的形式对代码进行模块微服 (高内聚务,数据和代码都从物理上隔划分,控制得当即可实现高务架 低耦合)离开来,实现高内聚低耦合相内聚。但最终都是在数据层构胜 对容易 面将整个系统耦合在一起 系统设计独立开发新模块,通过AP在现有系统上修改,与现存微服 (扩展 与现有模块交互 业务逻辑高度耦合 务架 性) 构胜 需求变更各个微服务组件独立变更,容需要了解整个系统才可以正微服 响应速度 易实施敏捷开发方法 确修改,容易导致不相关模务架 块的意外失败 构胜 系统升级各个微服务组件独立升级,上需要了解整个系统才可以正微服 效率手和开发效率高,影响面小确修改,容易导致不相关模务架 块的意外失败 构胜 7运维效率大系统被拆分为多个小系统 简单直接 单体 部署和运维难度加大,但可以 架构 利用 DevOps等方式将运维 胜 工作自动化 知识积累微服务组件可以在新项目中直一般以共享库的形式复用后微服 接复用,包括前端页面 台代码 务架 构胜 91硬件需求一个系统需部署多个微服务,整个系统只需夏一个运行容单体 (简单项需要启动多个运行容器 器 架构 胜 92硬件需求按需为不同业务模块伸缩资源为整个系统分配资源,导致微服 (高要求 节点 冗余 务架 项目) 构胜 10.1项目成本项目早期和后期,成本变化曲项目早期成本低,后期成本单体 (简单系 线平缓 大 架构 统) 胜 102项目成本项目早期和后期,成本变化曲项目早期成本低,后期成本微服 (复杂系 线平缓 大 务架 统) 构胜 11非功能需为单独的微服务按需调优,甚为整个系统调优,牵一发而微服 求 至更换实现方式和程序语言 动全身 务架 构胜 12职责、成拥有明确的职责划分,主人翁职责不明确,容易产生扯皮微服 就感意识和成就感加强,容易形成 行为 务架 自组织型团队 构胜 13 风险大系统被拆分为小系统,风险系统是一个整体,一荣俱微服 可被控制在小系统内,但也引 荣,一损俱损 务架 入了各小系统之间的交互风阶 构胜 结论: 对于简单项目来说,单体架构5胜8败。(优势项:开发效率、上手难度、 运维效率、硬件需求、项目成本;劣势项:系统设计(高內聚低耦合)、系统 设计(扩展性)、需求变更晌应速度、系统升级效率、知识积累、非功能需 求、职责、成就感、风险) 对于复杂项目来说,单体架构2胜11败。(优势项:上手难度、运维效 率;劣势项:硬件需求、项目成木、开发效※、系统设计(髙内聚低耦合) 系统设计(扩展性)、需求变更响应速度、系统升级效率、知识积累、非功能 需求、职责、成就感、风险;) 、微服务与共享库的对比 注:这里以使用方自行安装微服务为场景来比较。这里的共亨库指的是像 Java中的公共jar依赖。 S/N对比 微服务 共享库 结论 点 易用 整体安装+AP|调用 共享库引用+本地调用平手 性 2程序微服务为完整的业务逻辑单元,在使用方的源代码中引用共享平于 耦合通过AP|的形式为其它模块提 库的类和方法 度 供服务 版本单独升级,其它模块无感知修改源代码,升级使用方的代微服 升级 码版本,例如 pom. xm.务架 build gradle 构胜 4Bug单独升级,自动生效修改源代 微服务架构胜 修复码,升级使用方的代码版本,例 如 pom xn, build gradle 非功为单独的微服务优化或扩缩容;为整个业务系纷优化或扩缩微服 能需在需求更高的情况下,可以重新容,共享库的程序语言必须和务架 求 设计或使用不同的程序语言 业务系统的程序语言相同构胜 6复用可以复用从前端页面到后台数据可以复用后合代码和数据库,微服 程度 库的整个业务逻辑和代码但程序语言需要和业务系统保务架 持一致 构胜 什么场景需要用微服务架构? 看了上面的比较,微服务架构可以说是以压倒性的优势胜过单体架构和共享 库,会让人产生一种错觉,微服务架构就是软件开发中的银弹。 但是,正如大家所了解的,软件研发是一个系统工程,它没有银弹,不能够 招鲜吃遍天。正如当年的CMMⅠ和敏捷方法一样,敏捷虽好,但它不一定能 适用于所有的场景,它对组织环境、团队氛围、沟通方式、技术能力这些都是 有一些要求的,如果用不好,反而会带来一些负面影响。 那么,我们什么时候需要采用微服务呢?从我个人的经验来看,我认为有三种 场景可以考虑使用微服务。 1.规模大(团队超过10人) 2.业务复杂度高(系统超过5个子模块) 3.需要长期演进(项目开发和维护周期超过半年) 这里借一张图来说明: for less-complex systems, the extra baggage required to manage microservices reduces productivity as complexity kicks in, productivity starts falling the decreased coupling of microservices reduces the attenuation of productivity Productivity M Icroservice Monolith Base Complexity but rememl /:# sk o the wil outweigh any monolith/microservice choice 横轴是复杂度,纵轴是生产效率。从生产效率的角度来讲,在两条曲线的交叉 点之前,单体架构是占优势的,过了交叉点之后,单体架构的生产效率将大幅 度下降。 所以很多专家和同行朋友都说,我们可以在开始的时候先使用单体架构,当业 务发展到一定程度的时候,再重构成微服务架构。对于这一点,我是持保留意 见的,因为在实践中,架构改造的难度还是很大的,会有一些问题,例如 客户或业务部门是否给我们这样的时间窗口? 这段时间的研发经费是否有出处? 项目负责人或技术团队是否有主动的意愿进行架构升级? 项日负责人或技术团队是否愿意为架构升级带来的不稳定风险负责? 我们常常听到的一句话是:暂时先这样,等我们没这么忙的时候,再来优化 下。但是,绝大多数情况下,这一天从来没有出现过。 再想想年初,我们的私有云平台经过2年多的发展,已经包含了容器服务平 台(Paas)、API网关、监控平台、定时任务平台、数据库管理、用户权限 管理等等十多个基础模块,也包含了一些为上层应用服务提供的口志服务、缓 存服务、消息服务等等。并且,部署到了二十多个客户的生产环境里。可悲的