解决方案:没有银弹，微服务架构改造的一条不归路。。。

　　解决方案:没有银弹，微服务架构改造的一条不归路。。。

　　本文将介绍微服务架构和

　　相关组件，它们是什么以及为什么应该使用微服务体系结构和这些组件。

　　本文重点简明扼要地介绍微服务体系结构的大局，因此不涉及组件使用方式等细节。

　　要了解微服务，

　　我们必须首先了解那些不是微服务，并且通常与微服务相反的单体应用程序，即将所有功能打包到单个单元中的应用程序。

　　从单体式应用程序迁移到微服务并非一蹴而就，而是一个渐进的过程。

　　本文将以在线超市应用程序为例来说明此过程。

　　初始需求

　　几年前，Bob和Pi一起开了一家网上超市。Bob 负责程序开发，Pi 负责其他事务。

　　当时互联网还不发达，网上超市还是蓝海。只要实现该功能，就可以随便赚钱。

　　所以他们的需求很简单，只需要一个网站挂在公网，用户就可以在这个网站上浏览商品、购买商品;此外，还需要管理背景来管理产品、用户和订单数据。

　　让我们把功能列表放在一起：

　　由于要求简单，鲍勃左手和右手慢动作，网站准备就绪。管理后台出于安全原因没有跟网站做，小明的右手和左手慢动作重播，管理网站也做了。

　　整体架构图如下：

　　小明摆了摆手，找了个云服务部署，网站就上线了。推出后好评如潮，受到各种肥宅的喜爱。萧明开始躺下收钱。

　　随着业务的增长...

　　好景不长，没过几天，各种网商纷纷纷纷效仿，对小明小皮造成了强烈冲击。

　　在竞争的压力下，鲍勃·小皮决定实施一些营销策略：

　　这些活动需要对程序开发的支持。小明拉着同学小红加入队伍。小红负责数据分析和移动开发。Bob 负责开发与促销相关的功能。

　　因为开发任务比较紧迫，小明小红没有把整个系统的架构规划好，随口拍了拍脑袋，决定把推广管理和数据分析放在管理后台，微信和手机APP分开构建。

　　几天一夜之间，新功能和应用程序几乎完成了。

　　此时，体系*敏*感*词*如下：

　　现阶段有很多不合理之处：

　　尽管存在许多问题，但这一阶段的结果是不可否认的：该系统是为响应业务变化而快速构建的。

　　然而，紧急和繁重的任务往往会导致局部的、短视的思维和妥协的决定。

　　在这种建筑中，每个人都只关注自己的英亩和三块土地，缺乏整体的、长期的设计。从长远看，制度建设会越来越困难，甚至陷入不断推翻重建的循环。

　　是时候做出改变了

　　

" />

　　好在，晓明和小红都是有追求、有理想的好年轻人。意识到问题后，小明和小红从琐碎的业务需求中腾出一些精力，开始梳理整体架构，准备改造问题。

　　要进行转换，您首先需要有足够的精力和资源。如果你的需求方（业务人员、项目经理、老板等）太专注于推进需求，以至于你无法投入额外的精力和资源，那么你可能什么都做不了。

　　在编程的世界里，最重要的是抽象的能力。微服务转换的过程实际上是一个抽象的过程。小明和小红梳理了网商的经营逻辑，抽象出了常见的经营能力，做了几项公共服务：

　　每个应用后台只需要从这些服务中获取所需的数据，从而去除了大量冗余代码，留下了轻薄的控制层和前端。

　　此阶段的结构如下：

　　此阶段只是分离服务，数据库保持共享，因此烟囱系统的一些缺点仍然存在：

　　数据库成为性能瓶颈，并且存在单点故障的风险。

　　数据管理往往是混乱的。即使一开始有良好的模块化设计，随着时间的推移，总会出现一个服务直接从数据库中的另一个服务中提取数据的现象。

　　数据库表结构可能依赖于多个服务，影响整个身体，难以调整。

　　如果保留通用的数据库架构，整个架构将变得越来越僵化，失去微服务架构的意义。

　　于是，小明和小红大打出手，也把数据库也分开了。所有持久性层彼此隔离，由每个服务负责。

　　此外，为了提高系统的实时性能，增加了消息队列机制。

　　架构如下：

　　完全拆分后，单个服务可以采用异构技术。例如，数据分析服务可以使用数据仓库作为持久层，以方便高效的统计计算;访问产品服务和促销服务的频率比较大，因此增加了缓存机制。

　　抽象公共逻辑的另一种方法是使其成为一个通用的框架库。此方法减少了服务调用的性能损失。但是，此方法的管理成本非常高，并且难以保证所有应用程序版本的一致性。数据库

　　拆分也存在一些问题和挑战：例如，需要跨数据库级联，通过服务查询的数据粒度厚度等。但这些问题可以通过声音设计来解决。总体而言，数据库拆分是一种利大于弊的拆分。

　　微服务架构还有一个额外的技术优势，它让整个系统的分工和责任更加清晰，每个人都专注于为他人提供更好的服务。

　　在单体式应用时代，常见的业务功能往往没有明确的归属。最后，要么做自己的事情，每个人都重新实现;要么是一个随机的人（通常是更有能力或更热情的人）在应用程序中做他负责的事情。

　　在后一种情况下，这个人除了要对自己的申请负责外，还要另外负责把这些公共职能提供给别人——而这个职能本来是不负责任的，只是因为他更有能力/热情，就莫名其妙地责怪锅（这种情况也得到了有能力者的称赞）。结果，没有人愿意提供公共功能。

　　随着时间的推移，团队中的人员逐渐变得孤立，不再关心整体架构设计。

　　从这个角度来看，微服务架构的使用也需要对组织结构进行相应的调整。因此，做微服务转型需要管理者的支持。

　　装修完成后，小明和小红分清楚了各自的花盆。两人非常满意，一切都像麦克斯韦方程组一样美丽完美。

　　而。。。。

　　没有灵丹妙药

　　春天来了，一切都复活了，又是一年一度的购物狂欢节。看到日订量不断上升，小皮小明和小红笑了。

　　可惜好景不长，音乐极度悲伤，突然系统挂断了电话。

　　过去，对整体式应用程序的问题进行故障排除通常是查看日志并研究错误消息和调用堆栈。但是，微服务架构的整个应用分散在多个服务中，很难找到故障点。

　　Bob 逐台检查日志，并一次手动调用一个服务。经过十多分钟的搜索，Bob 终于找到了故障点：由于收到大量请求，促销服务停止响应。其他服务直接或间接称为促销服务，因此它们也下降了。

　　在微服务架构中，单个服务故障可能会产生雪崩实用程序，从而导致整个系统出现故障。事实上，在假期之前，小明和小红已经做过请求量评估。正如预期的那样，服务器资源足以支持假日的请求数，因此一定有问题。

　　但是情况紧急，每一分一秒都白花一秒过去，所以Bob来不及排查问题，马上在云上搭建几个新的虚拟机，然后逐个部署新的提升服务节点。

　　

" />

　　经过几分钟的操作，系统终于勉强恢复正常。整个失败时间估计损失了几十万的销售额，三个人的心都在滴血......

　　之后，Bob 简单编写了一个日志分析工具（量太大，文本编辑器几乎打不开，肉眼看不见），统计了推广服务的访问日志，发现在失败期间，商品服务会因为代码问题，在某些场景下发起大量的推广服务请求。

　　这个问题并不复杂，小明手指一抖，修复了这个价值数十万的bug。问题

　　已解决，但不能保证不会再次发生类似的其他问题。虽然微服务架构在设计上逻辑上是完美的，但它就像一座由积木建造的华丽宫殿，经不起风。虽然微服务架构解决了老问题，但它也引入了新问题：晓

　　明晓红决心要把这些问题解决好。故障的处理一般从两个方面入手，一方面尽量减少故障发生的概率，另一方面减少故障带来的影响。

　　监视 - 发现故障迹象

　　在高并发分布式场景中，故障经常在雪崩中爆发。因此，有必要建立完善的监控系统，尽可能多地发现故障迹象。

　　微服务架构中有许多组件，每个组件需要监控不同的指标。例如，Redis 缓存一般监控内存占用、网络流量、数据库监控连接、磁盘空间、业务服务监控并发、响应延迟、错误率等。

　　因此，如果做一个庞大而全面的监控系统来监控各种组件，这是不现实的，可扩展性会很差。

　　一般做法是每个组件提供一个接口（指标接口）来报告其当前状态，并且该接口输出的数据格式应保持一致。

　　然后部署指标采集

器组件，定期从这些接口获取和维护组件状态，并提供查询服务。最后，您需要一个UI来从指标采集

器查询各种指标，绘制监控界面或根据阈值发出警报。

　　大多数组件不需要自己开发，网络上有开源组件。Bob 下载了 RedisExporter 和 MySQLExporter

　　这两个组件分别为 Redis 缓存和 MySQL 数据库提供指标接口。微服务根据每个服务的业务逻辑实现自定义指标接口。

　　然后 Bob 使用 Prometheus 作为指标采集

器，Grafana 配置监控界面和电子邮件告警。设置了这样的微服务监控系统：

　　定位问题 - 链接跟踪

　　在微服务体系结构中，用户的请求通常涉及多个内部服务调用。为了定位问题，您需要能够记录微服务中生成了多少服务调用以及每个用户请求时的调用关系。这称为链接跟踪。

　　让我们用 Istio 文档中的链接跟踪示例来查看效果：

　　图片来自：

　　从图中可以看出，这是用户访问产品页面的请求。

　　在请求过程中，产品页面服务会按顺序调用详细信息和评论服务的接口。评审服务在响应过程中调用评分接口。

　　整个链路跟踪的记录是一棵树：

　　若要实现链接跟踪，每个服务调用在 HTTP 标头中至少记录四项数据：

　　此外，还需要调用日志采集

和存储组件，以及显示链接调用的 UI 组件。

　　以上只是极简的解释，链接追踪的理论基础可以在谷歌的Dapper中找到。

　　在了解了理论基础后，Bob 选择了 Zipkin，这是 Dapper 的开源实现。然后，他用手指轻弹，为HTTP请求编写了一个*敏*感*词*，生成这些数据以注入每个HTTP请求的HEADERS，同时异步将呼叫日志发送到Zipkin的日志采集

器。

　　解决方案:如何根据不同类型候选人自动匹配信息采集方案？

　　1.1 功能介绍

　　对不同类型的候选信息采集方案进行差异化管理，避免单一方案与企业实际业务不匹配。

　　1.2 应用场景

　　正式员工和实习生的信息采集内容会有所不同，企业在实际业务中可以针对不同国家不同类型的员工采集不同的信息。

　　1.3 系统路径

　　【HR中台服务云】→【业务规则管理】→【战略管理】

　　

" />

　　2 主要操作

　　第一步：添加信息采集方案

　　操作地址：【芯人云】→【玩美入口】→【基础配置】→【信息采集配置】

　　第二步：进入业务规则管理→策略管理配置页面

　　操作地址：【HR中央服务云】→【业务规则管理】→【战略管理】→【业务云】→【核心人力资源云】→【好玩入口】→【招生信息采集方案】

　　

" />

　　第 3 步：

　　3.1 点击“添加”，配置政策基本信息、适用机构等信息。

　　3.2 配置策略的具体规则。根据不同类型的员工配置不同的规则，详细配置可查看

　　如何定义和配置业务规则→策略？()

　　3.3 确保规则配置无误后，最后提交并通过。