关于微服务的毕业论文题目

立即报名：10月24日AWS线上研讨会「使用云原生技术建构微服务应用加速创新」

今日的创新，成就明日的经典！美国学者多年前提出「创新扩散理论」（DiffusionofInnovationsTheory）认为：「因部分人的开放思想、更愿意接受新观念、尝试新形态策略，所以创新才能持续扩散开来。」如今，AI、巨量资料加快市场革新速度，「不创新，就等死」的警钟，不仅催促传统标竿企业迈开步伐转型，新创企业也想借此成功找到商机切入点。

在理论中，把创新分成五阶段，而你的企业是最后一阶的「落后者」，还是成为积极主动的领先「革新者」？台湾高达95%的企业属中小企业，许多企业主、IT主管一想到「创新」，脑中便浮现资源不足、流程复杂、人力不够等挑战；又或是因应市场变化，不知从何开发创新业务模式，种种困难成为企业求新求变的瓶颈。

而云端资源正好能够解决这个问题，现在透过云端服务应用，就能帮助企业节省资源，又能让经营者把心力专注放在业务策略。所谓「站在巨人的肩膀上」，在这里就是指「云原生（CloudNative）技术」让中小企业得以借力使力、有效调度企业资源、加快创新服务速度！

▲「创新扩散理论」五阶段。（左起）创新者、早起采用者、早期采用人群、后期采用人群、迟缓者；纵轴为市场份额。

业界有越来越多声音指出，传统的软体架构已经成为创新瓶颈。中小企业正期望通过简化管理机制，在更弹性、敏捷的系统架构下，获得更多微服务设计，让企业IT人员可直接在云原生环境，针对程式进行灵活的小幅改动，并快速部署验证商业模式，让创新服务快速落地。

身为全球最全面及广泛采纳的云端平台，AWS深知企业加速创新过程面临的痛点。过去在没有云端资源的情况下，经常遇到「想开发新服务，就必须买断软体授权，却又资金不足」的问题；或是缺乏IT专业人才，因而面临技术瓶颈；又或是用传统标准软体开发思维，不仅拖慢开发速度，做出的产品也早已与市场商机脱钩。

然而，现在情况不同了，AWS除了提供来自全球资料中心超过165项功能完整服务，更于每个月定期举办线上研讨会，让云端开发者社群进行交流。AWS近期将于10月24日举行线上研讨会，主题聚焦「使用云原生技术建构微服务应用加速创新」。

为什么传统软体架构造成创新阻碍呢？想像一个情境，如果把软体架构譬喻为石块，巨型架构是几块大巨石组成，在搬运上较笨重又不灵活。所以在巨型架构内的程序结合紧密，如果想扩增应用程式的程式码库，在更新维护的过程中，就会显得缺乏弹性；开发周期长，也会衍生需求落后风险。

▲微服务与巨型架构，就像是小碎石与大块巨石的差别。

此外，在巨型架构下，某个应用程式的其中一个程序需求新增，就必须扩展到整个架构更新；若是想添加程式码基底，巨型应用程式在调整过程也更显复杂。如果想引进新功能、语言、技术，便会因为巨型架构的每个应用程式蕴含大量逻辑，导致开发、维护及管理费时费力，大幅拖慢企业新业务进度。

「时间是企业最珍贵的资产」，云原生环境对此提供了一种微型服务架构，就像是把大巨石打碎成各样式小石子，小石子比巨石更具组合弹性。换言之，微服务即是在软体架构下，将应用程式建立为独立元件，各小型独立元件可各别执行应用程式程序，以利每项服务执行单一功能，且每项服务皆独立运作。

而微型服务架构就像小碎石之于巨石，能更快速部署、去中心，每项功能可透过定义API进行通讯，达到良好隔离优势。且因为各别服务的形式会在自己的容器内执行，实现独自扩展、轻松部署，又可重复使用程式码、恢复能力，相当符合台湾中小企业实务需求，轻松加速商业创新。

呼应的创新扩散理论，他提到创新具备几种要素，包含「便利性、兼容性、可靠性」等，这些要素也正是AWS微型服务平台的重要特质。企业搭建软体服务首重运算处理功能，AWS因此针对微服务的发展需要，提供AWSElasticContainerService（AmazonECS）以及AmazonElasticKuberesService(AmazonEKS)容器服务，并可在EC2的丛集上轻松执行应用程式。又或者，在无伺服器环境下，AWSLambda不用布署伺服器就可使用执行程式码，不仅发挥高可用价值，也拓展程式码所需的各项工作；此外，也能透过AWSECSFargateM，让部署容器应用程式时，也不需要管理伺服器。

当然，除了运算需求，在资料储存应用服务方面，AWS也提供以NoSQL为基础的AmazonDynamoDB资料库，协助开发人员建立无伺服器应用程式，快速读取和写入请求，解决传统关联式资料库不堪负载的问题。另外，还有专门从云端建立的MySQL、PostgreSQL相容的关联式资料库——AmazonAurora资料库，具备开放原始码优势。相较传统硬体执行的标准MySQL，AmazonAurora更提供高于MySQL五倍的效能。

从运算、储存、联网、监控，到DevOps管理，各项服务在AWS上建构微服务时，可以依据需求「单样点餐」或「一次全打包」，一切依据企业使用量付费。同时，AWS灵活动态的服务组合与搭建的系统架构，可以支援各种应用程式架构的设计，让企业不再受规模、负载或复杂度的限制。在前往创新路上，AWS可说是企业的最佳伙伴。

本次「使用云原生技术建构微服务应用加速创新」线上研讨会，AWS将分享客户案例「爱料理」及「D-Link」，分别阐述AWS服务帮助他们解决实务的商业问题，进而达到业务目标。

台湾最大料理社群平台「爱料理」，透过AmazonAurora获得多重协助，包含横向地达到扩展的便利性；或纵向地借由AmazonRDSPerformanceInsights省下开发除错的时间成本。随着爱料理近年积极布局影片食谱市场，AWSElementalMediaConvert及相关服务遂成为爱料理开发新业务的重要基石。在影音工程开发人才有限情况下，AWS以最先进的服务技术，为企业省下大量的投资成本，把更多心力投注在其他业务开发上。

身为全球知名网通领导品牌的D-Link，在过去执行物件辨识的服务开发过程中，因为高密集业务请求，连带造成高量CPU执行情况。为了解决这项问题，D-Link借由AWSLambda的协助，不仅解决突然涌入的超高需求量CPU负荷，同时大幅提升客户的使用体验，并且达到成本控制的多层效益。D-Link团队表示：「非常感谢AWS的Serverless服务，让我们能够更快部署以及测试服务。」

上述案例将在线上研讨会上有更细致说明，同时AWS解决方案架构师将跟观众分享在AWS平台上如何快速运用云原生相关服务，找到适合自身企业商业模式的相关技术工具。AWS观察到，多数成功拥抱云端的企业，其关键心态（Mindset）是勇于接受改变，并且在「上云」过程，尝试更贴近云环境，恰当发挥云端价值。将繁琐的技术托付给AWS云原生环境，企业将有更多心思专注在业务服务价值。

企业永续发展过程，「创新」永远是商场致胜的利器，更多更省时省力的作法，都在10月24日的AWS线上研讨会「使用云原生技术建构微服务应用加速创新」。欢迎企业借此盘点手上现有资源，以及思索商业模式如何再创新。展望未来，从巨人肩膀站得更高看得更远，让创新不再是难事！

在传统的单应用架构下，接口的日志监控还是非常简单的，但是随着分布式、微服务架构的兴起，我们会面对更为复杂的服务交互关系； 也就是说，以往的系统，更多的是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都可以的