微服务改造过程中那些必须重视的问题

　　＂微服务＂近几年尤其火热，各大厂都在进行微服务化改造和微服务建设，想享受微服务化带来的好处以便对自己的系统进行改造。分布式实验室特约记者李鹏采访了广州轻阅科技系统架构师陈珙，就微服务与SOA的区别与联系、企业引入微服务会带来的问题以及解决方案和陈珙自己的工作经验进行了交流。  李鹏：谈到微服务都不可避免的会提到SOA，请问微服务与SOA有区别与联系？分别适用于什么场景？
　　陈珙：果然一谈到微服务，SOA也绝对不会避而不谈。首先，对于这个问题我也曾经思考与总结过的，我的看法跟大多数人百度、Google到的那种看法并不一样，下面我将从两者的发展史、两者的出发点与核心思想进行阐述。
　　SOA与微服务的关系，我从多个方面的资料梳理后，总结出有这样两种看法：  微服务是SOA的最佳实践 （出自维基百科）—— 微服务是SOA的演进版，粒度更细，基础设施去中心化。  微服务拒绝SOA的标签 （出 Martin Fowler 的《Microservices》原文）——微服务与SOA，是两个完全不同的架构风格，只不过刚好长得像。
　　首先是发展史，这里我整理了微服务发展的小历史。
　　时间
　　事件
　　2005年
　　Peter教授在Web Servces Edge大会提出了＂Micro-Web-Services＂
　　2007年
　　JuvalLöwy在他的著作与演讲建议用服务构建系统，并意识到细粒度因此扩展了WCF。
　　2011年
　　一个软件架构工作组在威尼斯附近举行的软件架构师研讨会上使用了＂Microservice＂来代表这种架构模式
　　2012年
　　Jame Lewis针对微服务概念在某大会发表了演讲
　　2014年
　　Jame Lewis和Martin Fowler合写了关于微服务的一篇学术性文章
　　从上文我们可以总结出三个核心关键点：  微服务的起源最早追溯到2005年；  微服务不是由 Martin Fowler 他本人创造的；  那篇举世闻名2014年写的《Microservices》原文是由 Jame Lewis 和 Martin Fowler 他们两人共同合作编写的。
　　虽然说微服务架构并非 Martin Fowler 所创造的，但是称《Microservices》这篇文章是推动微服务的崛起的缘由，一点都不为过，而 Jame Lewis 和 Martin Fowler 两位对微服务的盛行起到了非常关键的作用。
　　我相信不少同行讨论微服务都会拿维基百科的定义作为标准（维基百科仍然写着微服务是SOA的一种变种），不得不承认，微服务当时的出现就是作为一种轻量化的解决方案，用来解决SOA的一些诟病的，但是随着微服务的这些年的发展与蜕变，渐渐的脱离了SOA的标签，成为了一种独立的架构风格。
　　因此在2014年 Jame Lewis 和 Martin Fowler 合作编写的《Microservices》其中一段写着微服务倡导者拒绝SOA的标签。因此我认为维基百科的定义已经过时了。
　　接着说两者的出发点与核心思想，我认为，要看清楚它们关系的本质，就得从两者各自的处理场景目的出发。
　　首先从微服务角度出发，因为单体应用的大而全的高耦合与臃肿，随着业务的发展迭代的时间越久，就会有各种各样的问题，因此通过把应用拆成了多个＂小＂的服务，这里使用到了化繁为简、分而治之的核心思想，解决原有单体的＂痛点＂和＂难点＂。
　　接着从SOA的角度出发，在当时那个年代，希望把各种异构的系统给整合起来，这些异构的系统，有可能是从其他地方买的，也有可能是研发的，也有可能是找外包做的，因缘由存在各种不确定性，所以希望通过一个＂聪明的＂ESB解决所有的＂愚蠢的＂问题，也是因此ESB的高复杂度，导致当年SOA那会只是炒得火热，却无法普遍落实。
　　总地来说，微服务以拆与约定作为出发点，而SOA是以整合与配置作为出发点，所以我个人认为从它们的出发点与目的的角度出发，直接决定了它们在本质上是完全不同的架构。 所以我更加倾向于《Microservices》原文提到的看法，微服务的倡导者拒绝SOA这个标签的。
　　以上就是我对SOA与微服务的关系的一些见解。
　　李鹏：团队引入微服务技术会不会带来新问题？比如会带来什么新问题？应该怎么解决？
　　陈珙：引入微服务的话，从我的经验来看还是会带来不少的问题，我自己还是总结了一番，用一句话概括：两文化与一思维。   自动化文化、可观测性文化和分布式系统思维。
　　首先是自动化文化，有些人觉得疑惑，自动化这种能给团队省时省力、减少重复工作量、增加幸福度的技术难道还有人或者团队会抗拒的？是的，还真的有。
　　我曾经就接触过几个团队的Leader，他们的团队都是推行自动化失败了。 失败的原因就在于成员不配合，成员拒绝配合的理由是：这么多框框条条很麻烦麻烦、没有自己亲手去做总觉得机器不靠谱。
　　作为已经使用过自动化的其他同行来看，这样的思想完全觉得不可思议，但是我却可以理解，大家回忆下自己是否曾经对没使用过的框架与技术引入到生产同样会产生＂恐惧＂、＂担心＂，是的，从某角度来看这是＂谨慎＂，但是过于谨慎了。
　　重新回到话题，从上面可知，统一团队的目标一致性是有必要的，从另外的角度来看，自动化还需要团队、项目的流程的标准化、统一与约定，任何的技术都无法脱离了业务与团队而去讨论应该如何去实施。
　　作为技术领导者推行优良的方案，是我们的职责之一。如果团队成员无法配合，导致推行受阻，我们一共有三种应对策略：激励、考核和逐步试行。如果有条件的公司可以设置奖金激励，如果有绩效考核的，可以将自动化的实施纳入考核目标，如果这俩都没有，那就选取团队里愿意改变的同事牵头试行，假如使用过后都说好，那么会更有说服力。
　　其次是可观测性文化，如果说自动化是给团队带来稳定性，减轻工作量的，那么可观测性就是提高团队对系统运作的信息量。 建立可观测性的这项工作，虽然无法直接给系统带来健壮性，但能够使我们通过这些信息充分地了解到系统正在运作的情况，以至于最大程度地做出最合适的定位、判断与决策。
　　在单体应用的场景下，我们也是需要可观测性的，但是单体的架构相对简单，项目调试也更加便捷，无论是从复杂度还是规模的角度来看，单体跟微服务相比都要低不少，也因此单体对可观测性的需要，相比于微服务显得没那么重要。
　　而我们只要进行了微服务实施后，因为应用被拆分成了细粒度，从而导致了架构从量变引起质变，这个时候可观测性的作用在微服务场景下被＂无限放大＂，也因此我们利用＂可观测性＂，给与我们提供应用与服务器的监控、快速跟踪与问题定位的功能。
　　可观测性的三个要素日志、跟踪、指标。 我们在工作中只有灵活结合这三者，才能提高我们对系统运行情况的信息量，信息量越高思考的越是更加全面，才能尽可能地减少＂不知道问题出在哪＂的状况，所以当我们不清楚具体发生问题的原因时，建议你侧重做一件事：就是尽可能想办法，提高我们对问题与系统的信息量。
　　在这里额外提醒一句，自动化与可观测性并不是必须跟微服务架构绑定，无论在哪里的业务，怎样的系统，在条件允许的情况，越早把这两者完善，那么长期收益则越高。
　　最后就是分布式系统的问题，这个问题又分为三个，幂等性、数据的一致性的读与写。
　　幂等性， 其定义是 相同的参数在同一个方法里，无论执行一次还是多次都会响应相同的结果。
　　对于查询和删除的场景都有天然的幂等性，那么我们考虑幂等性的处理，更多是关注于新增数据与更新数据。
　　新增数据缺乏幂等性，则会因为网络抖动导致请求重试或者是客户端重复点击，而引发的数据写入重复，其解决方案也相对简单，只要从客户端生成主键传给后端API就可以解决，在这里得注意一点，只有请求成功或者主动刷新才会重新生成主键。
　　更新数据缺乏幂等性，主要会造成两种情况，数值错误自增和ABA问题。首先，数值错误自增，可以结合事务凭据与新增幂等性的方式解决。
　　而ABA问题，解决方案相对简单，可以在更新操作时带上版本号判断进行解决。
　　ABA问题： 对某条记录先更新了A数据，紧接着又更新了B数据，理应是B是最新的，但是因为其他客观原因使接口Retry或者别的问题，导致A数据再次请求覆盖了B。
　　幂等性处理方案
　　场景
　　问题
　　方案
　　新建数据
　　重复创建
　　由调用端预生成订单号，唯一键约束
　　更新数据
　　ABA覆盖问题
　　添加版本号判断
　　金额自增
　　使用流水凭据
　　数据一致性读，其实说白了就是做数据关联，从我过往用的解决方案来看共有三种，应用层的接口聚合数据、把更新频率低的字段冗余存储、把数据库同步到一台服务器进行SQL联表处理，每种方式各有优缺点，我结合切身体会和过往经验，以表格方式整理呈现出来，你可以根据业务场景自行选择解决方案。
　　数据关联方案
　　方案名称
　　方案描述
　　优点
　　缺点
　　应用层数据聚合
　　分别调用查询API，在业务逻辑层组装，适用于简单的关联。
　　实现简单
　　该方案只能适合简单的查询过滤，以主表为驱动的关联
　　冗余设计（反范式）
　　在目标表添加冗余字段，适用于记录递增的，不适用于冗余字段更新频繁，实现起来简单，有扩展性问题
　　实现简单，以应用层数据聚合方案有更多的过滤条件
　　冗余的字段如果更新存在同步问题，该方案适用于更新频繁少的递增日志类数据
　　数据库从库集成
　　通过主从同步把相关表同步到一台服务器做跨库查询，适用于复杂查询、报表类的，有技术复杂度，从长远收益来看能应对多种场景
　　通过强大的SQL解决复杂的报表类查询
　　拥有技术复杂度，需要数据库主从处理
　　写的数据一致性，其实就是分布式事务，主流的方案有 TCC 、 本地消息表（基于消息可靠的最终一致性） 、 异步请求/回调。   其他的多数是基于以上几种方法的变种，例如RocketMQ的消息事务，就是TCC+本地消息表的变种。
　　分布式事务方案，用文字描述起来相对比较吃力，因此我通过流程图代替文字描述展示给大家。下方表格是我对这三种方案的优缺点与使用场景的总结。
　　分布式事务方案
　　名称
　　场景
　　优点
　　缺点
　　异步请求/回调
　　跨网络环境、同网络环境
　　实现简单
　　强业务
　　TCC
　　跨网络环境、同网络环境
　　有现成的框架、实现简单
　　强业务
　　基于消息可靠的最终一致性
　　同网络环境
　　有现成的框架、通用性强
　　中间件依赖
　　以上就是我所经历微服务的引入后所需要解决的一些问题与方案。
　　李鹏：工作这么长时间，你在微服务改造过程中有没有遇到特别大的困难，都是怎么解决的？
　　陈珙：这个问题勾起了我的痛并快乐着的回忆。俗话说得好，万事开头难，因此第一次做微服务的实施经历给我带来了非常深刻的印象。
　　第一次做微服务是2019年，受老领导的邀约加入了新公司并以微服务架构风格来从零开始搭建新系统。这也是我工作多年以来，第一次以技术负责人的身份，从零开始组建自己的团队，同时从零开始开发系统，而且还是得用当时对我来说＂陌生的＂微服务架构。
　　我面临的第一个难题就是我的运维能力。 如大家所了解的运维就是微服务架构的地基，如果运维能力有限那么微服务搭建的规模与完整度自然也会受到影响。在当时来说，我以往工作经验，接触运维还是比较少的，因此在实施微服务的同时不得不进行恶补运维的知识，像容器化、Linux基础、网络知识、自动化等等。
　　因此，当时我买书与课程应该属于我这么多年以来的最疯狂的一次，每天早上在地铁上学习，下班后回家也会带着问题找资料，现在回想起来也非常的充实。
　　第二个难题就是.Net的技术生态。 .Net并没有一套像Java一样比较成熟的、默认的方案，因此在.Net微服务的技术选型上花了不少的时间与精力，主要的问题体现在到各种框架与中间件之间的集成，很多时候还要自己看源码改扩展。
　　从现在看过往，真正允许我们.Net选择的框架与中间件并不是很多，因为很多中间件是不提供.Net SDK的。而且在当时来说，在技术社区里也没多少人会分享自己.Net微服务实战的心得，因此对于我们不得不摸着石头过河，无论觉得行还是不行都得尝试一遍，最终总结出适合自己的技术选型。
　　事后，我也希望后来人避免踩坑，在博客园写了个《.Net微服务实战》系列，在给自己做总结的同时也分享给有需要的同行。
　　第三个难题则是微服务的划分。 大家可能都知微服务拆分的其中一种方式是按照业务边界，DDD的战略思想与事件风暴被我引入到了工作当中，不得不说DDD战略的化繁为简与微服务的分而治之这两种思想是非常契合的。
　　但并不是说这种方式在任何时候都完全适用，因为我们整个团队都是新组建的，业务对我们来说都是全新的，因此不存在领域专家这一个说法。在整个工作当中会存在很多不明确的业务，一般这个时候我们是不做任何服务的拆分处理的，只有随着我们对业务的熟悉度越来越了解，才慢慢地再去重新识别业务边界从而进行拆分。
　　虽然说微服务减轻了开发人员的开发负担，但是对于架构师来说是一件非常考验综合能力的事情。
　　李鹏：请给新手提一些建议，微服务改造应该怎么上手？改造过程中需要注意什么？
　　陈珙：在上个问题，我拿了自己当时作为新手时实施的经历，大家也可以参考下。那么接下来我会总结一下，从多个方面出发进行分享。
　　从硬技能角度出发。 大多数微服务设计者是从开发过来的，因此开发技能无需过多担忧，但是运维技能肯定对于他们来说是偏弱的，还是那句话运维是架构的地基，所以运维的基础能力得优先提高。
　　这里得注意一下，并不是说需要大家的运维技能一下子成为专家级的，这样也不现实，但是起码得够用，能和专业运维岗无缝沟通，因为作为团队的技术领导者，很多时候得领先团队做技术调研、技术选型与评估，而拥有这些基本的能力，能让自己更加顺利的衔接好团队并完成工作。
　　从软能力角度出发。 如我上面所说的，微服务非常考验架构师的综合能力，那么沟通与管理也包含在内。微服务的实施是需要整个团队配合的，每个人都有自己擅长的专业与领域，因此团队之间的能力是互补的。
　　从康威定律可以了解到，团队里成员之间的比例与技能是跟系统架构相匹配的，那么架构师作为团队的衔接点、承上启下的角色，更加应该有良好的沟通协助方式与大局意识。
　　想要一个人承担所有的角色搭建整套微服务架构，我认为是不现实的，特别是对有一定规模的老系统进行改造，里面会有数不尽的＂坑＂，脱离了业务进行架构设计无疑是＂耍流氓＂，技术服务于架构，架构服务于业务，业务服务于商业，这是一条不变的真理。 软件工程是一项多人协作的工作，每个岗位都有他存在的价值与意义，这里没有个人＂英雄主义＂。
　　从实施的流程出发。 微服务里用了不少中间件，例如：API网关、服务注册中心、负载均衡器等等，在不是特别必要的情况下，可以稍微延后这些中间件的搭建，我们可以先把重心放到可观测性与自动化的搭建上。
　　自动化与可观测性在微服务架构中有着无法代替的重要性。 因为在微服务架构中由于服务的拆分慢慢的从量变引起了质变，原本在单体架构中显得不重要的流程与问题会逐渐的被放大。当然了，自动化与可观测性并不是说得准备要微服务才应该着手准备，无论在哪种系统来说，能越尽早完善自动化与可观测性，那么收益就会越大，只有系统稳定了，不会每天被那些繁琐的维护工作占用过多的时间，我们才可以有时间与机会做更加有意义的事情。
　　从新旧系统改造出发。 新的系统使用微服务的难点主要在于第一次搭建微服务的＂陌生感＂，当你形成一套可复用模式后，后续第二次、第三次就如同＂堆积木＂。
　　旧系统的改造一般来说会比新系统的复杂点，主要的原因是旧系统是有稳定业务的，因此我们在对旧系统的服务拆分时更多的考虑的是，哪些业务模块相对耦合性低，可以优先独立出来，拿旧系统试错还是有一定的风险与成本，因此我们尽可能减少影响面，适当的还要考虑功能的兼容性与发布的可逆性。
　　原文链接：https://mp.weixin.qq.com/s?__biz=Mzg5Mjc3MjIyMA==&mid=2247553425&idx=1&sn=139504f458e247276d8e8f23e720f4e9&utm_source=tuicool&utm_medium=referral