微服务论文题目

在传统的单应用架构下，接口的日志监控还是非常简单的，但是随着分布式、微服务架构的兴起，我们会面对更为复杂的服务交互关系； 也就是说，以往的系统，更多的是A系统调用B系统，而现在可能面对这A->B->C->D，而在这种情况下，如果没有链路跟踪的方案，那么查找和定位问题就会非常困难。理论基础 Google公司研发了Dapper分布式跟踪系统，并发表了论文《Dapper, a Large-Scale Distributed Systems Tracing Infrastructure》； 目前行业内大部分的分布式跟踪方案都是基于这篇论文来实现的；这篇论文中提到了几个比较重要的概念：A：parentId=null、spanId=1； B：parentId=1、spanId=2； C：parentId=2、spanId=3； D：parentId=2、spanId=4；实现方案 我将持续分享Java开发、架构设计、程序员职业发展等方面的见解，希望能得到你的关注。 集成zipkin或者spring cloud sleuth都可以的

通信

1、GSA：全球5G商用网络已达200张 5G终端已发布1257款

根据全球移动供应商协会（GSA）的最新更新，截至2021年12月底，78个国家/地区的200家运营商已经推出了一项或多项符合3GPP标准的5G服务。GSA还报告称，72个国家/地区的187家运营商已经推出了5G移动服务，45个国家/地区的83家运营商推出了符合3GPP标准的5G固定无线接入服务。“通过全新的、基于云的、虚拟化的、基于微服务的核心网基础设施，引入5G SA技术的一些预期益处包括更快的连接时间、对海量设备的支持、能够更快更灵活创建服务的可编程系统和网络切片（在切片中对SLA管理的支持得到了改善），以及新空口承载语音（VoNR）的出现。”GSA称，“5G SA的推出将有助于简化架构、提高安全性并降低成本。5G SA有望实现定制化，并为企业、行业和政府客户量身定制新的服务和收入机会。”

2、中国信通院：2021 年我国 5G 手机出货量达 亿部

今日中国信通院发布消息，称 2021 年我国 5G 网络建设日趋完善，用户数屡创新高。随着 2021 年 7 月《5G 应用“扬帆”行动计划（2021-2023）》的推出，截至 2021 年 12 月底，各省市共出台各类 5G 扶持政策文件 583 个，其中省级 70 个，市级 264 个，区县级 249 个。统计结果显示，截至 2021 年 11 月底，我国累计建成 5G 基站 万个，覆盖全国所有地级以上城市市区、超过 97% 的县区以及 50% 的乡镇镇区。电信运营企业共建共享 5G 基站超过 80 万个，促进 5G 网络集约高效发展。5G 行业虚拟专网为工业、矿山、电力、物流、教育、医疗等垂直行业企业充分利用 5G技术优化生产管理、赋能转型升级提供了必要的网络条件。截至目前，我国建成并商用的 5G 行业虚拟专网已超过 2300 个。

智慧城市

3、《城市数字孪生标准化白皮书（2022版）》正式发布

近日，由全国信标委智慧城市标准工作组组织编制的《城市数字孪生标准化白皮书（2022版）》（以下简称“白皮书”）正式发布。白皮书由中国电子技术标准化研究院联合中国信息通信研究院、腾讯云计算(北京)有限责任公司、软通智慧 科技 有限公司、深圳市南山区政务服务数据管理局、盈嘉互联（北京） 科技 有限公司、北京五一视界数字孪生 科技 股份有限公司、中国联合网络通信有限公司智能城市研究院、华为技术有限公司等41家单位共同编制。当前，城市数字孪生已经发展成为支撑智慧城市的重要技术手段。为做好城市数字孪生标准化工作整体规划，有序推动相关标准制定与应用实施工作，全国信标委智慧城市标准工作组组建了城市数字孪生专题组，并组织编制了白皮书。白皮书在系统研究城市数字孪生内涵、典型特征、相关方等基础上，构建了城市数字孪生技术参考架构，梳理了城市数字孪生关键技术和典型应用场景，总结了城市数字孪生发展现状、发展趋势、面临的问题与挑战及国际国内标准化现状。在此基础上，白皮书 探索 形成了“城市数字孪生标准体系总体框架（版）”，并提出了拟研制标准建议和标准化工作建议。白皮书构建了城市数字孪生标准化路线图，为后续相关标准研制、应用实施指明了方向。

工业

4、阿里云为100座垃圾焚烧炉装上工业大脑，全年可多发亿度绿电

据悉，全国近30个城市的100座垃圾焚烧炉已装上阿里云工业大脑，通过AI技术使生活垃圾焚烧的环保指标更稳定，单位发电量提升，全年可多发亿度绿电，相当于一个中型水电站的发电量。据阿里云智能制造与能源电力技术总经理孔令西介绍，全国有近30个城市的100座垃圾焚烧炉都已引入阿里云工业大脑，北至吉林松原，南到广东佛山。通过AI技术提高生活垃圾发电效率，全年可多发亿度绿电。据了解，到今年年底，全国约300座垃圾焚烧炉将应用工业大脑AI技术。

5、工信部：到2023年初步建立建材行业智能制造标准体系

工信部印发《建材行业智能制造标准体系建设指南（2021版）》，明确到2023年，初步建立建材行业智能制造标准体系，制定不少于20项相关标准；对于智能化水平较高的细分领域，实现智能装备、智能矿山、智能工厂标准基本覆盖，重要的智能服务、智能赋能技术、集成互联标准有所覆盖；其他细分领域优先制定智能工厂标准；实现重要关键技术标准在行业示范应用。到2025年，建立较为完善的建材行业智能制造标准体系，制定不少于40项相关标准；智能化水平较高的细分领域智能制造标准较完善；其他细分领域智能工厂标准全面覆盖，重点智能服务、智能赋能技术、集成互联标准有所覆盖；实现智能制造标准在行业广泛应用。

6、冬奥赛时全部场馆常规能源 100% 使用绿电，有望实现碳中和

根据财联社消息，北京冬奥组委总体策划部部长李森在国新办新闻发布会上介绍，北京冬奥充分利用北京 2008 年奥运会的场馆，从源头减少碳排放，同时建设低碳场馆，所有场馆都达到了绿色建筑标准。具体来看，四个冰上场馆使用了新型二氧化碳制冷剂，建成超过 5 万平米的超低能耗示范工程，全面使用低碳能源，赛时全部场馆常规能源 100% 使用绿电，构建低碳交通体系，节能与清洁能源车辆在赛时车辆中占比超过了 8 成，通过这些措施北京冬奥会将全面实现碳中和。

医疗

7、男子植入人工心脏需要每天充电

1月13日，山东青岛。经过一段时间的治疗和康复训练后，山东省首例人工心脏植入患者在青岛大学附属医院顺利出院。不过，与别人不一样的是，患者黄先生的“心脏”每天都需要充电。二十多天前，黄先生因终末期心力衰竭，在该院成功植入了一个国产的“第三代全磁悬浮人工心脏”，恢复情况良好，但从此黄先生随时都要携带一个黑色的小挎包，这个外部装置通过一根经过腹部皮下隧道的细电线与“人工心脏”连接起来，装置包括电源、可充电电池以及一个监控器，给予“人工心脏”电力支撑。

网络安全

8、Facebook面临200亿索赔 被指收集4400万用户数据

近日，社交媒体巨头Facebook母公司Meta在英国面临一桩索赔金额超23亿英镑(约合32亿美元)的集体诉讼，该公司被指控滥用其市场支配地位，利用4400万用户的个人数据。诉讼称，Facebook通过强加不公平的条款和条件，要求消费者交出宝贵的个人数据以访问该网络，从而赚取了数十亿英镑。Facebook表示，人们使用它的服务是因为公司为他们带来了价值，而且“他们能够有效控制在Meta的平台上分享什么信息以及与谁分享”。

9、小米手机被污“审查”信息？德国BSI：查无实据

1月13日，德国联邦信息安全办公室（BSI）向小米公司发出通知，确认没有证据表明小米手机存在“审查”功能。2021年9月，一份出自立陶宛的“产品调查报告”声称，在欧洲销售的小米手机具有内置检测和审查功能。对此，BSI进行了三个半月的调查，并最终得出结论：没有发现任何异常情况，也不需要进一步调查或采取其他措施。针对前述报告，通知特别指出：“BSI无法侦测到原报告提及的过滤列表的传输行为。” 小米发言人表示，很高兴BSI证实了小米遵守欧盟和各国的数据隐私和安全法律。市场调研机构Canalys显示，2021年三季度欧洲智能手机市场中，小米份额排名第二，是欧洲销量最高的中国手机企业。

10、全国首例刷单案宣判，百度获赔205万元

因认为网络公司通过设置广告任务发布平台等行为，帮助用户制造虚假点击数据，扰乱排序结果，原告北京百度网讯 科技 有限公司（百度）将被告深圳市我爱网络技术有限公司（我爱网）诉至法院，要求判令被告消除影响并赔偿经济损失及合理开支共计500万元。海淀法院经审理，一审判决我爱网登报消除影响并赔偿经济损失200万元及合理开支5万元。该案系全国首例涉人工刷量平台干扰搜索引擎算法不正当竞争纠纷案。

元宇宙

11、虚拟数字人发展提速，多家银行宣布“造人”

12、分析师：元宇宙兴起 芯片制造商或成最大赢家

据国外媒体报道，分析人士表示，随着元宇宙的爆火，全球芯片制造商或成为这一竞赛中的最大赢家，相关技术不断涌现，其他 科技 相关行业也将从中受益。新加坡商业银行星展银行（DBS Bank）首席投资官Hou Wey Fook表示：“元宇宙真正的赢家实际上是 科技 公司。并且由于需要巨大的计算能力，吃到最大红利的将是半导体公司。” 一份 财经 分析报告称，元宇宙中涉及到的海量数据的实时处理需要其芯片包含高级处理节点，只有台积电、三星和英特尔符合要求；像联合微电子、中芯国际等规模较小的芯片厂可能只能从供应链中价值较低的部分获益。

AI

13、三星宣布世界首款搭载 MRAM 非易失磁阻内存的电脑：可用于 AI 运算

据外媒 techpowerup 报道，三星电子今日正式公布了世界首款搭载 MRAM 内存的电脑，相关论文发表在《Nature》网站，并即将在杂志上发表。论文题目为《用于内存内计算电脑的磁阻存储器件交叉阵列》，相关电脑可以用于 AI 运算。目前的计算机大都采用独立的 RAM 内存以及独立的硬盘存储，但是为了提高运算效率，业界一直在开发非易失的内存，能够兼顾硬盘和内存的功能，同时有助于大大降低功耗。为了实现这一目标，研究人员开发了 RRAM（电阻随机存储器）、PRAM（相变随机存储器）等，已经有了原型机。三星采用的 MRAM（磁阻非易失随机存储器）具有高速、耐用、容易量产等优点，但是由于功耗问题，此前迟迟没有正式亮相。具体来看，研究者成功开发了一种新的 MRAM 阵列，通过新型“电阻”和计算架构，替换当前采用的架构。据了解，搭载 MRAM 内存的电脑经过 AI 运算性能测试，识别手写数字的准确度达到了 98%，人脸识别准确度达到了 93%。

传感器

14、TOF 在消费类电子市场遇冷，消息称今年仅苹果一个高端玩家

根据韩国消息称，三星公司正计划重新设计在高端智能手机上使用相关传感器镜头，并考虑放弃 TOF 传感器。换句话来说，三星 Galaxy S22 系列或将取消搭载 TOF 镜头。针对目前 TOF 的市场现状，一位资深的业内人士向笔者透露，“在手机这一市场，2022 年仅苹果一个玩家配备 TOF，其它家都没有配备 TOF 的产品。” 该人士认为，TOF 在手机市场还将会打持久战，目前各大手机品牌厂商都在折叠屏上下功夫，而 TOF 要等 AR 市场起来其价值才能更好的得以体现。深究其原因，该人士坦言，目前 TOF 这一市场还缺乏应用，但是从根本上来说，还是由于手机厂商利润薄导致。

智慧教育

15、小米集团与全国多家高校共建小米工作室，旨在培育专项人才

据小米官方发布，目前，小米集团与全国多家高校共建的小米工作室陆续揭牌启用，小米集团 2021 年与高校的人才合作工作顺利收官。同时，小米携手国内多家高校的合作历程进入新阶段。首批小米工作室已在清华大学、电子 科技 大学、哈尔滨工业大学、西安交通大学、南京大学等 14 所国内知名高校落地。小米集团深刻意识到：人才培养的主体是高校，产业实践的经验在企业。在当前就业环境的大背景下， 社会 对人才提出了全新标准，高校的人才培养目标、模式也需要与时代要求良好衔接。通过小米工作室校企协同育人的新理念，采用更灵活的教学模式、更高的服务标准、更好的技术平台，为 社会 培养更多具有家国情怀、追求卓越的高素质、高技能、重创新的复合型人才。

微服务作为架构风格几乎成为云时代企业级应用的事实标准，构成微服务的技术元素本身却并非革命性。跨平台的分布式通信框架、地址无关的服务注册与发现、智能路由与编排等技术早已在CORBA、SOA时代实现了一遍又一遍，我们不禁好奇，微服务有什么不同？本文是对企业分布式应用的一次回顾，与前微服务时代相比，我们究竟在哪些领域吸取了教训，哪些方面持续搞砸。 架构的关键在于构造合理的封装抽象。良好的抽象构造如进程，由操作系统接管CPU调度、内存地址空间分配和I/O，程序员的心智从此解放，得以聚焦在业务逻辑上。糟糕的抽象往往引向万丈深渊，大量精力被浪费在抽象泄露带来的问题上。 让我们从组件间的通信开始，最初人们认为这只是需要被解决的技术要素。关于如何实现跨平台的分布式通信，30年前诞生的CORBA架构在今天来看仍然非常漂亮：通过定义IDL/ORB/API我们可以将内存对象任意分布于网络中。只要共享IDL，对象可以由C++/Java等不同的语言实现，其互相调用就像本地方法一样简单。然而实践经验告诉我们，分布式系统总是会出现本地调用不会发生的各种问题：网络的开销、传输的延迟、消息的超时和丢包、远端系统的崩溃……物理世界的技术约束是无法被忽略的，我们没有办法把分布式调用抽象成简单的本地方法。因此Martin Fowler在他的< 企业应用架构模式>里提出了著名分布式对象第一定律：“不要分布式你的对象”。相反，你应该把尽可能多的操作置于进程之内，通过replicate整个应用的方式来实现系统的scale。 由分析师们发起的SOA运动从另一个角度看待这个问题，Web Service应该是对企业资产和业务能力的封装。我们开始站在更高的维度，远过程调用不再只是技术意义上的集成。WSDL不仅是通信调用的接口，更是服务间的契约；UDDI不仅是服务描述、发现、集成的中心，更是企业业务与服务的黄页。WS-*在厂商的裹挟下发展成包罗万象，却也没几个人能掌握。开发者们抱怨花了太多时间写冗余的XML制定所谓的规范，WSDL生成的客户端也将不同服务耦合在一起。是否有更加轻量敏捷的方式，让我们快点开始写第一行生产代码？ 于是我们看到REST的兴起。起初是作为反叛，用更加轻量级的方式(http+json)使用Web。然后我们发现”企业级”应用并非需要ESB这样昂贵的专有中间件，由”消费级”技术组成的万维网是世界上最大规模的分布式网络，我们应该向其学习如何构建健壮、可演化的系统。Roy Fielding那篇论文所提出的无状态、可缓存等特征已经深入人心，而狭义上的REST API(基于资源的URI、HTTP动词和状态码的标准接口)也成为API设计的最佳实践。 既然API和网站一样都是基于通用Web技术，API是否可以像网站一样作为产品提供呢(APIs as product)？于是越来越多的企业开始将自己的业务能力封装成API，提供给消费者，随之而来的是更弹性的商业应用和更灵活的计费方式。很多组织也着手构建自己的API市场，把内部IT能力整合、复用，并为孵化外部产品做准备。API已经成为商业价值主张的一部分。 我们从聚焦实现细节的rpc出发，来到了更具价值导向的REST API。即使构建内部系统，以消费者驱动的方式，也总是能帮助我们设计出更加松耦合和易于演进的API。 编程语言中的组件构造(如Java中的jar, C#中的dll)是软件架构师们封装可复用单元的最常用武器。组件作为理论上的最小部署单元，在工程实践中却并不容易独立变更。一般应用程序需要讲多个组件打包成一个部署单元(如war包)，链接在内存地址中进行调用。对单个组件的热更新往往对组件间耦合和对象状态管理有很高的要求，重新部署整个应用一般是默认选项。以进程为边界构建可独立部署的服务成为架构师的另一项选择。 早期的服务只是单纯的技术构件，大多数组织从纯粹的技术实现角度考虑服务的划分。SOA的推动者们指出企业的信息资产应该被复用，信息孤岛应该被打通。通过将不同的服务编排组合，我们应该能够实现IT对业务更加灵活的支撑。SOA的服务建模一般采用业务流程驱动的方式。一个典型的SOA设计是由业务分析师自顶向下地对企业现有业务流程进行分析，通过BPM引擎对流程进行建模，向下分解成组合服务，并进一步拆分成数据访问服务(很多可怜的SOA实现中数据的访问被拆分成不同的读服务和写服务)。然而这带来的问题是，服务跟服务间的耦合非常严重。当我的业务发生了变化，可能会需要修改很多不同的服务，涉及到多个团队的沟通和协调。在运行时层面，服务器间的通信非常频繁，用户在界面上的一次点击按钮，对应的后台多层服务间的级联通信。这给系统性能和稳定性也带来了巨大的挑战。SOA式的服务建模从分析型思维出发，却往往低估了分布式系统和跨团队协调的复杂度，导致服务拆分粒度过细。 微服务的名字常常让人误解，但实施正确的微服务粒度可能并不”微”。Martin Fowler与James Lewis在开创微服务定义的一文中已经指出微服务应该围绕完整的业务能力。今天我们在做微服务设计时，常常利用领域驱动设计中的Bounded Context来进行服务边界的划分。假设你的库存管理是一个独立的业务子域，针对库存的维护和操作应该被放到通过一个上下文和微服务中，由一个团队进行开发维护。多数业务变更都发生在上下文内部，不涉及跨团队协调。单个codebase内的重构和部署让发布更加容易。维护库存所需要的信息查询的调用多发生在进程内，更好的性能，同时无需处理额外的一致性问题。如今我们对服务的定义已经超越了技术组件，领先的组织已经在尝试将design thinking, business operating model应用到微服务设计中。 即使有了设计合理的服务于API，我们仍然需要与之匹配的工程实践才能将其顺利实施。 今天仍有很多企业使用集中式的应用服务器部署应用：开发团队将软件包构建出来，再统一安装到应用服务器中。对应用团队来说，这往往意味着漫长的反馈周期和痛苦的自动化。我们很早就推荐用Jetty这样内嵌式的应用容器部署软件，启动更快，测试环境更接近生产。one Tomcat per VM的部署方式虽然运行时开销较大，却是前容器时代隔离性最好的服务部署模式。Docker将这个实践更进一步，除了更轻量级的隔离，我们第一次可以将软件和所依赖的环境本身打包成版本化的artifact，彻底统一开发和生产环境。容器技术的成熟让我们可以将部署去中心化，开发团队可以独立部署一个服务。 数据库耦合是影响服务独立变更的另一重要因素。相比代码构成的应用软件，数据库schema更加难以变动。因为难以测试、难以兼顾性能优化和耦合的发布周期等因素，服务间以数据库集成成为臭名昭著的反模式。服务间的集成应该依赖封装好的显示接口，而不是数据库这种实现细节。我们应该在兼顾数据一致性的情况下，为每个微服务分配独立的db schema甚至db instance。如果说十年前数据几乎等同于关系数据库。如今数 据则可能呈现出各种形态：键值、文档、时间序列、图…我们完全可以采用更加合适的技术，以去中心化的方式进行微服务的数据治理。 即使将这一切都解耦，如果将交给一个集中的团队去实施，很有可能最终还是得到一个耦合的架构。这就是是著名的康威定律。康威定律告诉我们“设计系统的架构受制于产生这些设计的组织的沟通结构”。但同样我们可以将康威定律反转应用：如果你想达成一个目标架构，则必须对团队结构进行调整，使之和目标架构对齐。相比单体系统，微服务在运行时监控和运维所带来的挑战更大。”you build it, you run it”的DevOps文化成为必须。监控运维不再是Ops部门的事情，产品团队必须对微服务的整个生命周期负责。授权的去中心化自治团队是实施微服务的必要条件。 我们在很多方向的确取得了进展。但即使在微服务时代，很多问题仍然在轮回发生着，似乎我们总是无法吸取 历史 的教训。让我们看一看那些挥之不去的反模式阴云。 另一个挥之不去的阴影是ESB。ESB在将异构的应用wire在一起有着关键的作用。然而当越来越多的职责被加入：数据报文的裁剪转换、难以测试和版本控制的编排(orchection)逻辑、服务发现智能路由监控治理分布式事务等All in One的solution将ESB变成了一个可怕的单点梦魇。所以微服务发出了“智能终端哑管道”的呐喊：我们只是需要一个不那么智能的代理处理可靠消息传输，将灵活的逻辑交给服务本身去编配(choreography)吧。 于是在典型的微服务架构里，负载均衡、服务注册发现、分布式追踪等组件以Unix way的方式各司其职。然而在利益诱惑和特性竞争压力之下，很多厂商不断将更多的功能放进他们的中间件，其中为代表的Overambitious API gateways俨然要重新实现占据中心的ESB。如果API gateway只是处理鉴权、限流等横切层逻辑没有问题，如果API gateway开始处理数据转换和业务逻辑编排，你应该提高警惕！ 尽管行业在不断发展，但很多时候人们仍然沿用旧的思维，用新的技术去一遍遍重新实现这些旧的反模式。 你总是可以在技术雷达里追踪微服务的state of art，如今这个领域的前沿方向是什么，Service Mesh, Chaos Engineering, 还是Observability as Code？然而 历史 告诉我们，新的技术在解决一些问题的同时，也可能会产生新的问题。更糟糕的是，我们永远无法记住 历史 ，用新的工具更高效地重现旧日问题。 Technologies come and go, Principles stay forever。好在那些架构和实践背后的原则是经久不变的。从操作系统到移动应用都会需要高内聚低耦合的架构，任何软件开发都需要版本控制、自动化构建等实践。谨记这些核心原则、谨记软件被创造出来是为了解决有价值的问题，可以帮我们更好的借鉴 历史 的经验，理解和采纳新的技术。 文/ThougtWorks刘尚奇 本文首发于刘尚奇个人网站：