服务之美-读《微服务设计》笔记全集(一)

最近在微信读书上读《微服务设计》一书,目前读了30%多了,其间想法有点多,现分享给大家。

微服务设计

Sam Newman

阅读笔记

共享库不要轻易的使用?

>> 但是你还是需要很小心,如果使用共享代码来做服务之间的通信的话,那么它会成为一个耦合点。

模块化在为服务中并不是很好的实践?

>> 除了把系统划分为不同的服务之外,你可能也想要在一个进程内部使用模块进行划分,但是仅仅使用模块划分不能解决所有的问题。如果你只使用Erlang,可能会花很长时间才能把Erlang的模块化做好,但是我怀疑大部分人不会这么做。对于剩下的人来说,模块能够提供的好处与共享库比较类似。

调用链监控

>> 能够清晰地描绘出跨服务系统的健康状态非常关键。

代码治理

>> 尽量通过技术的手段把更多的规则固化。比如代码风格,各种工具和插件,所采用的技术方案。

技术债务

不光走捷径会引入技术债务。有时候系统的目标会发生改变,并且与现有的实现不符,这种情况也会产生技术债务。

一个系统中或多或少都会存在一些债务,只要这些债务在某个点得到遏制和升级。亡羊补牢 犹未迟也。就像我们每个人一样谁身上还没有一两个伤疤。比如,有的代码实现,逻辑比较混乱,直到几个迭代下来,你才真正理清了内的的逻辑,此时,你要在新的实现中果断的,对之前的代码进行固化,或者叫隔离,新的实现就基于新的思路来实现。这样你的代码中相当于有两个思路的代码实现存在,一种是之前的现在看来有问题的代码,一种是更成熟的代码实现。之前的那点存在的代码就是伤疤。技术债务随着迭代的持续,得到了升级,从而得到有效的遏制。

然后你可以把这个伤疤标记todo,待日后进行彻底迁移。这算是技术债务列表的一种实现方式。

服务自治和易修改

>> 赢得世界的方法是,保证自己很容易对应用进行修改。这正是微服务的用武之地!

谨慎过早的划分微服务

曾经遭遇过过早划分微服务,过早划分一般很难定义好边界。因为需求什么的根本就不稳定。除非需求非常明确,或者有一个非常资深的架构师甚至专家级别的大佬坐阵。否则,会比较费力。

>> 很多时候,将一个已有的代码库划分成微服务,要比从头开始构建微服务简单得多。

为别人提供微服务的正确姿势

我们很多时候为别人提供微服务,首先问对方一句话:你要哪些数据?其实这样的出发点也许是不对的,是不是可以从提供功能的角度来提供一个更加通用的微服务?

同样的,当你在思考组织内的限界上下文时,不应该从共享数据的角度来考虑,而应该从这些上下文能够提供的功能来考虑。

逐步划分上下文

>> 通常很难说哪种规则更合理,但是你应该根据组织结构来决定,到底是使用嵌套的方法还是完全分离的方法。

嵌套上下文还是隔离上下文,取决于组织架构和团队边界。如果几个上下文都是由一个小组的人负责,你把这些独立开来后,反倒不好管理。但这种思考角度似乎有点问题,虽然表象上可以讲通。应该是根据上下文内的服务的负荷程度来决定才更具本质。

技术边界

按照技术去划分服务的后果基本不可想象。但按照技术接缝对服务边界进行建模也并不总是错误的。比如,我见过当一个组织想要达到某个性能目标时,这种划分方式反而更合理。然而一般来讲,这不应该成为你考虑的首要方式。

寻找理想的集成技术

>> 如果你从事IT业已经超过15分钟,不用我说也应该知道,你工作的领域在不断地变化,而唯一不变的就是变化。新的工具、框架、语言层出不穷,它们使我们的工作更高效。现在你在做.NET,那一年之后呢,或者五年之后呢?说不定什么时候,你会想要尝试一个能够让你的工作更有效率的技术栈。 我很喜欢保持开放的心态,这也正是我喜欢微服务的原因。因此我认为,保证微服务之间通信方式的技术无关性是非常重要的。这就意味着,不应该选择那种对微服务的具体实现技术有限制的集成方式。

?,作为一个RPC的日常使用者,曾经也主张这种技术无关性。也就是微服务应该采用更加标准的,与具体技术和语言无关的集成技术,比如REST。但,我目前使用过的微服务集成技术中,除了中途使用过一段时间Spring Cloud(算是REST吧),其他的比如Dubbo以及现在公司自研的服务框架都是基于RPC的。当然了,基于thrift的RPC算是一种更加通用的,更加“技术无关性”的集成技术了。但大部分时候,还是使用基于RPC,然后生成客户端桩代码进行远程调用。使用客户端会造成耦合,但对于开发者来说确实是很方便,很多时候一个技术能不能流行起来取决于使用者到底欢不欢迎它。

共享数据库

数据库是一个很大的共享API。多个不同的组织以及服务共享一个数据库,一个数据库表,真的是一场无法预期的灾难。

>> 数据库是一个很大的共享API,但同时也非常不稳定。

编排vs协同

服务组装有两种方式,一种是通过编排,一种通过协同(事件订阅)。前者偏重,导致上帝节点出现,而其他节点变为贫血,只是crud;而协同模式采用事件机制,则有效的解耦,但需要一个额外的监控系统来跟踪每个订阅后的行为是否正常结束,如果失败了,那么要考虑补偿和善后。

>> 通常来讲,我认为使用协同的方式可以降低系统的耦合度,并且你能更加灵活地对现有系统进行修改。但是,确实需要额外的工作来对业务流程做跨服务的监控。我还发现大多数重量级的编排方案都非常不稳定且修改代价很大。基于这些事实,我倾向于使用协同方式,在这种方式下每个服务都足够聪明,并且能够很好地完成自己的任务。

REST

json的轻量级让人们不假思索就用了起来,包括我们绝大多数,但其实有的场景下偶尔使用xml或者html会有更好的效果。但json依然是主流。xml和html作为返回格式,只在特定场景下才适用。比如富媒体。

>> 不过我个人来讲还是很喜欢XML的,因为在工具上有很好的支持。举个例子,如果我只想提取负载中某个特定部分的话,可以使用XPATH,而支持XPATH标准的工具相当多。CSS选择器也可以,并且用起来还更简单。使用JSON的话,也有JSONPATH可用,但是目前支持该标准的工具很有限。我感觉很奇怪的是,很多人选择JSON是因为它很轻量,但是又想方设法把超媒体控制之类的概念添加进去,而这些概念是在XML中早已存在的。

Reactive

在微服务中使用reactive是一件让人听起来就略微激动的事情,可以基于spring提供的reactive来做push。得看场景。

>> 响应式扩展(Reactive extensions, Rx)提供了一种机制,在此之上,你可以把多个调用的结果组装起来并在此基础上执行操作。调用本身可以是阻塞或者非阻塞的。Rx改变了传统的流程。以往我们会获取一些数据,然后基于此进行操作,现在你可以做的是简单地对操作的结果进行观察,结果会根据相关数据的改变自动更新。一些Rx的实现允许你对这些被观察者应用某种函数变换,比如在RxJava中就可以使用类似map或者filter这样的经典函数。

微服务世界中的DRY和代码重用的危险

服务内部遵循dry,跨服务之间可以适当反dry,就好比以前我们搞代码脚手架,如果是通过maven依赖来搞模版,那么后果就是一旦你的公共库改掉,所有的项目都跟着改了,这显然是一个巨大的common包的共享,强耦合。所以此时大家一般采用复制冗余的方式来保证接耦合,然后通过脚手架约定来做到模版化。

>> 跨服务共用代码很有可能会引入耦合。但使用像日志库这样的公共代码就没什么问题,因为它们对外是不可见的。Realestate.com.au使用了很多深度定制化的服务模板来快速创建新服务。他们不会在服务之间共用代码,而是把这些代码复制到每个新的服务中,以防止耦合的发生。

版本管理

不同接口共存是一个很棒的做法。事实上包括jdk都是这样做的,然后通过@Deprecate。

>> 如果已经做了可以做的所有事情来避免对接口的修改(但还是无法避免),那么下一步的任务就是限制其影响。我们不想强迫客户端跟随服务端一起升级,因为希望微服务可以独立于彼此进行发布。我用过的一种比较成功的方法是,在同一个服务上使新接口和老接口同时存在。所以在发布一个破坏性修改时,可以部署一个同时包含新老接口的版本。

用户界面

有时候,你可以让服务端负责提供一部分UI,看起来看棒。但依然存在一些问题,比如一致的用户体验。往往前端和服务端有可能不是一个团队,此时就比较麻烦,但如果是面向业务的团队则这方面的问题就会稍微好一点,但即使一个团队内部,也会因为前端和后端不是一个人,而导致风格会不一致。

>> 这种方式有一个工作得很好的变种,即将一系列粗粒度的UI部分组装起来。也就是说不再创建小部件,而是对胖客户端应用的所有内容或一个网站的所有页面进行组装。

与第三方软件集成

很多产品买之前说得天花乱坠,一旦付钱后,事情就变得复杂了。所谓定制是对系统架构设计非常合理的前提下暴露了的api定制接口,对技术要求比较高。一旦不合理,你定制的那些扩展。等他们下个版本稍微升级一下就可能变得不可用。

>> 很多企业购买的工具都声称可以为你做深度定制化。一定要小心!这些工具链的定制化往往会比从头做起还要昂贵!如果你决定购买一个产品,但是它提供的能力不完全适合你,也许改变组织的工作方式会比对软件进行定制化更加合理。

最好的定制是加个自己开发系统的一个链接?哈哈,我感觉是,这样是可控的。

>> 那么到底应该怎么办呢?你可以选择在CMS上面套一层自己的服务作为对外的网站,如图4-11所示。这时CMS就成为了一个服务,其职责是管理内容的创建和获取。在自己写的那个前端服务中,你可以按照自己的方式来写代码和做集成。你对网站的扩展具有很好的控制力(很多商业CMS提供了自己专用的插件来处理负载),那么就可以使用更合理的模板系统。

善用绞杀者模式

绞杀者模式就是把老系统接口拦截,然后决定是调用新系统接口还是继续走老系统。

>> 与在CMS系统前面套一层自己的代码非常类似,绞杀者可以捕获并拦截对老系统的调用。这里你就可以决定,是把这些调用路由到现存的遗留代码中还是导向新写的代码中。这种方式可以帮助我们逐步对老系统进行替换,从而避免影响过大的重写。

增量的方式拆分

其实万事都是这种做法。得分而治之,一点点增量来搞。时间长了,慢慢就变得越来越好。然而现实经常看到各种拉倒重来的做法,每做一件事情像是搞运动,看似热闹,其实是每隔一点时间归零后又重新起步。从这点讲,那些搞运动式的所谓项目最终只是“政客”们短期实现自己仕途目标的一个垫脚石。从这点延伸开来,一个人活着的意义究竟是仰望,还是俯视。有的人喜欢和比自己强的人在一起,而有的人则喜欢身边的人都不如自己。这种两种不同的选择,看到的东西也自然不一样。

>> 决定把单块系统变小是一个很好的开始。但我强烈建议你慢慢开凿这些系统。增量的方式可以让你在进行的过程中学习微服务,同时也可以限制出错所造成的影响(相信我,你一定会犯错的!)。

打破外键关系

自从微服务观念注入进来后,各种表关联的SQL就离我远去。

分布式事务

再做一次。其实也就是补偿。

>> 其实,对我们来说知道订单被捕获并被处理就足够了,因为可以后面再对仓库的提取表做一次插入操作。我们可以把这部分操作放在一个队列或者日志文件中,之后再尝试对其进行触发。对于某些操作来说这是合理的,但要保证重试能够修复这个问题。很多地方会把这种形式叫作最终一致性。相对于使用事务来保证系统处于一致的状态,最终一致性可以接受系统在未来的某个时间达到一致。这种方法对于长时间的操作来说尤其管用。在第11章中我们会讨论扩展(scaling)模式,届时会对该话题做进一步讨论。

可以把处理中的订单全部管理起来。包括处理状态。比如,异常状态,正常状态,未处理状态。异常状态中包含异常码,然后根据不同的异常码跳转至不同的补偿逻辑。等。支持手动和自动重试补偿。

>> 举个例子,你可以创建一个叫作“处理中的订单”的概念,围绕这个概念可以把所有与订单相关的端到端操作(及相应的异常)管理起来。

微服务中怎么实现报表

在传统的单块应用中,我们通过使用使用简单的cron定时对slave数据库进行查询然后生成报表。但在微服务中,你的数据分布在各个不同的库里。此时已经再使用传统的方式显然不能搞定。如果通过对方提供的服务来进行查询然后聚合,想想都可怕,显然也是无法实现的。此时推荐你通过事件源的方式,也就是通过消息订阅的方式来生成视图。

原文发布于微信公众号 - ImportSource(importsource)

原文发表时间:2018-11-26

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏人工智能

微信机器人-Python学习日志(1)

一直以来,这个号发的都是《狼人杀小程序的开发日志》,体现产品的思路比较多,从纯技术的角度看其实并没有很精彩。这次,来讲讲我在其他方面的探索吧。 众所周知,微信公...

5798
来自专栏CSDN技术头条

专访当当网张亮:深度解读分布式作业调度框架elastic-job

【编者按】互联网从诞生到现在,网站的规模不断扩大,存储和处理的数据量也远远超出了人们的想象,又随着对信息实时性、多媒体需求大幅增长的现象,互联网架构面临越来越大...

2476
来自专栏phodal

使用 adr 轻松创建 “程序员友好” 的轻量级文档

是的,我又写了一个 markdown 工具,它对我来说非常有用。 上下文 在一周里,我看到了一个名为 “轻量级架构决策记录” 的技术实践。在看到了一个简单的示例...

23910
来自专栏鹅厂网事

海量服务器安全高效管控系统设计

"鹅厂网事"由深圳市腾讯计算机系统有限公司技术工程事业群网络平台部运营,我们希望与业界各位志同道合的伙伴交流切磋最新的网络、服务器行业动态信息,同时分享腾讯在网...

3518
来自专栏魏琼东

基于DotNet构件技术的企业级敏捷软件开发平台 AgileEAS.NET - 系统架构

      本文是继AgileEAS.NET应用开发平台介绍及AgileEAS.NET之敏捷并行开发方法所做的架构补充,用于阐释AgileEAS.NET平台的架...

2025
来自专栏后端技术探索

性能优化模式(纯干货!!)

性能优化涉及面很广。一般而言,性能优化指降低响应时间和提高系统吞吐量两个方面,但在流量高峰时候,性能问题往往会表现为服务可用性下降,所以性能优化也可以包括提高服...

1414
来自专栏SDNLAB

如何确保uCPE零接触部署

服务提供商正在努力用在通用客户端设备(uCPE)的标准平台上运行的软件来替换客户端设备(CPE)。他们还希望尽量减少在供应链和客户现场建立uCPE所需的步骤。在...

972
来自专栏福利活动清单

新用户有哪些优惠——腾讯云篇

满200减150 / 满500减375 / 满1000减750 / 满2000减1500

1.6K2
来自专栏云计算D1net

私有云下的身份与管理解决方案

信息化时代,企业分布式管理模式的广泛应用使当今的IT系统管理变得复杂,企业必须提供一个全方位的资源审视以确保企业资源的有效访问和管理。而云计算的不断发展使得众企...

3958
来自专栏数据和云

遇见未来 | PostgreSQL:一匹即将发力的黑马

在2017年的DB-Engine的年度数据库榜单上,PostgreSQL以其超过其他341个受监控数据库管理系统的受欢迎程度居于榜首,被评为年度DBMS。其总体...

6507

扫码关注云+社区

领取腾讯云代金券