做技术选型就如网上购物一样，即使知道了它的优点，还得看看它的差评。我们得多方面评估，事先知道团队与业务是否能抵御与承受“坑”的风险。

既然任何一样技术都无法成为软件工程的银弹，那么必然解决了某种问题的同时，也会带来一些新问题，微服务也不例外。我回顾了下当时我实施时的难点确实有不少。不过，我个人认为微服务给我们带来最核心的问题主要有三点， 两文化 与 一思维 ：

上面这三个问题，每个的内容单独拿来出讲的篇幅，都足以出一篇完整的文章甚至是书，基于此我会挑一些重点和大家分享。当然，几乎每部分的文末，我会放入相关内容的文章外链，如果大家有兴趣可以自行扩展阅读。

任何的架构模式，也是需要同等的开发模式与之配合的 ，随着应用的拆分后服务的数量由 量变引起质变 ，因而需要接受自动化来代替从前的“人工处理”，包括服务的部署、服务注册发现等等。自动化，是软件工程的其中一种处理手段，允许团队采用主流的工具、流程形成一套自动化机制，从而减少重复性工作、减少人力干预的不确定性因素。

这里说说我对软件工程的理解： 通过多人协作、有目标、有步骤、有计划的，并使用科学方法论指导开发与维护程序的这个过程 ，也可以换成一条公式表达： 软件工程 = 工具 + 流程 + 模式 。

无论是我们讨论的这些 “事”、技术工具 ，还是 流程制度 都是需要 人（团队组织） 的参与， 人 的延申就是 团队与文化 ，就如上述所说的软件工程是多人协作的工作，只有当然团队目标一致，共同负责承担团队的项目，共同接受同一种文化才能很好的实施自动化。

我简单举个例子：如同多匹马拉车一样，只有它们都有共同的目标的 时候，才能快速拉车到目的，如果它们一匹向东一匹西，只会让马车无法前行甚至四分五裂。

说到这里有些人觉得疑惑，自动化这种能给团队省时省力、减少重复工作量、增加幸福度的技术难道还有人或者团队会抗拒的？是的，还真的有。

我曾经就接触过几个团队的Leader，他们的团队都是推行自动化失败了，失败的原因就在于成员不配合，成员拒绝配合的理由是：没有自己亲手去做总觉得机器不靠谱。我们先忽略他们的想法是对是错，回到团队与文化，从前面可知， 统一团队的目标 一致性是有必要的 ，作为技术领导者推行优良的方案，是我们的职责之一。

如果团队成员 无法配合，导致推行受阻，我们一共有三种应对策略： 激励、考核和逐步试行。

如果有条件的公司可以设置奖金激励，如果有绩效考核的，可以将自动化的实施纳入考核目标，如果这俩都没有，那就选取团队里愿意改变的同事牵头试行，假如使用过后都说好，那么会更有说服力。　

这部分就说到这里吧，基于此话题的内容比较多，广而泛，篇幅有 限，这里分享一篇我自己曾分享过的内容《.Net微服务实战之DevOps篇》（https://www.cnblogs.com/skychen1218/p/13096784.html），如有感兴趣的朋友，可看完整篇文章后自行有选择性、针对性地扩展阅读。

如果说自动化是给团队带来稳定性，减轻工作量的，那么 可观测性 就是 提高团队对系统运作的信息量 。建立可观测性的这项工作，虽然无法直接给系统带来健壮性，但能够使我们通过这些信息充分地了解到系统正在运作的情况，以至于最大程度地做出最合适的 定位、判断与决策 。

在单体应用的场景下，我们也是需要可观测性的，但是单体的架构相对简单，项目调试也更加便捷，无论是从复杂度和规模的角度来看，单体跟微服务相比都要低不少，也因此单体对可观测性的需要，相比于微服务显得没那么重要。

而我们只要进行了微服务实施后，因为应用被拆分成了细粒度，从而导致了架构从 量变引起质变 ，这个时候可观测性的作用在微服务场景下被“ 无限放大 ”，也因此我们利用" 可观测性 "，给与我们提供应用与服务器的监控、快速跟踪与问题定位的功能。

可观测性——可以由系统的外部输出推断其内部状态的程度，在软件系统中，可观察性是指能够收集有关程序执行、模块内部状态以及组件之间通信的数据

而可观测性三个维度组成： 日志（logging）、跟踪（ tracing）、指标（Metrics）。

因此基于上述总结，有 日志记录 才能清楚知道当前系统的运行状况和具体问题； 指标 是给与后续做优化和定位偶发性问题的一些参考，没指标参考就没标准；我们平常做得多的调试、查看调用栈也是跟踪的一种，但是在分布式时代，更多考量的是跨进程通信的 调用链路 。

日常有小伙伴曾问过我，如果出了那些很奇怪的问题，应该怎么定位、排查，本质上其实还是得提高我们对这个问题或系统的信息量。

例如：是哪个模块、接口出问题？具体服务器表现的情况是怎样？CPU还是IOPS高？具体报错是什么？

你看，说白了还是可观测性的三个要素日志、跟踪、指标。我们在工作中只有灵活结合这三者，才能 提高我们对系统运行情况的信息量 ，信息量越高思考的越是更加全面，才能尽可能地减少“不知道问题出在哪”的状况，所以当我们不清楚具体发生问题的原因时，建议你侧重做一件事：就是尽可能想办法，提高我们对问题与系统的信息量。

上文的自动化和可观测性，主要偏向于 运维层面 ，而作为后端开发人员更加关注的是 数据与应用服务的层面 ，特别是服务的拆分后，数据的一致性该如何处理。我相信这问题困扰着不少的后端开发，接下来我 将从 幂等性、数据的一致性的读与写 三个方向 ，跟大家分享一二。

幂等性的定义——相同的参数在同一个方法里，无论执行一次还是多次都会响应相同的结果

对于 查询 和 删除 的场景都有 天然的幂等性 ，那么我们考虑幂等性的处理，更多是关注于 新增数据 与 更新数据 。

新增数据缺乏幂等性，则会因为网络抖动导致请求重试或者是客户端重复点击，而引发的数据写入重复，其解决方案也相对简单，只要从客户端生成主键传给后端API 就可以解决，在 这里得注意一点 ， 只有请求成功或者主动刷新才会重新生成主键。

更新数据缺乏幂等性，主要会造成两种情况， 数值错误自增 和 ABA问题 。首先，数值错误自增，可以结合事务凭据与新增幂等性的方式解决。

而ABA问题，解决方案相对简单，可以在更新操作时带上版本号判断进行解决。

ABA问题

对某条记录先更新了A数据，紧接着又更新了B数据，理应是B是最新的，但是因为其他客观原因使接口Retry或者别的问题，导致A数据再次请求覆盖了B。

数据一致性读，其实说白了就是做数据关联，从我过往用的解决方案来看共有三种， 应 用层的接口聚合数据、把更新频率低的字段冗余存储、把数据库同步到一台服务器进行SQL联表处理 ，每种方式各有优缺点，我结合切身体会和过往经验，以表格方式整理呈现出来，你可以根据业务场景自行选择解决方案。

写的数据一致性，其实就是分布式事务，主流的方案有 TCC、本地消息表（基于消息可靠的最终一致性）、异步请求/回调。 其他的多数是基于以上几种方法的变种，例如RocketMQ的消息事务，就是T CC+本地消息表的变种。篇幅有限，这里分享一篇我曾经编写的文 章《.Net微服务实战之必须得面对的分布式问题》（ https://www.cnblogs.com/skychen1218/p/14346459.html）

分布式事务方案，用文字描述起来相对比较吃力，因此我通过流程图代替文字描述展示给大家。下方表格是我对这三种方案的优缺点与使用场景的总结。

从"拆"的层面来看 ，微服务的思想与优势给与开发人员带来了更多的便捷性，如 技术细节的隐藏 与 认知负担的降低 ， 使得开发人员更加关注自己负责业务代码的迭代。

但是， 拆了后还得重新整合 ，如果拆了无法整合，那么这样的设计是没有意义的。 从"整合"的层面 ，微服务大大提高了对架构师技能的要求，从通信交互到分布式问题，从自动化工程到可观测性，每一项对于架构师都是一种新的挑战。

无论是过去还是现在，只要聊到微服务总有个绕不过去的坎，那就是SOA。接下来，我会结合 《Microservices》原文 （）的 [Smart endpoints and dumb pipes]模块 ，简单聊聊微服务与SOA的之间的关系，有助于大家更好地了解为何微服务比SOA更容易实施与盛行。

在 《Microservices》原文 里有一个模块的标题是 Smart endpoints and dumb pipes ，如果用翻译直译成中文是[ 智能端点和哑管道 ]，我结合了自己的 经验并查阅了多种资料，最终认为 [ 强服务和弱通信] 作为它的翻译才更加合适。

微服务的 [强服务和弱通信] ，与SOA的 [弱服务和强通信] 是与之对应的，而 SOA架构的核心是ESB ，ESB主要功能有消息路由、协议转换、消息转换和应用业务规则的复杂。仔细观察下来，ESB基本上把微服务的基础设施该做的都做了，如此高的技术复杂度，也是导致SOA在过去那些年无法普及跟实施的根本原因。

ESB的 大而全 的特点，在文中描述到SOA的通信是“聪明的”（smart pipes），而我也因为ESB的特点给SOA的翻译是“强通信”。此外，我翻译的微服务的“ 弱通信 ”，并不代表通信的功能有限，而真正的意义是 弱化协议差异 ，使用统一、轻量级的通信协议，减少差异化、降低技术难度。

总地来说，基于两者在通信层面的对比，我们因此能总结出它们本质上的差异： SOA基于配置，微服务则基于约定 。