如今，关于微服务依然存在许多误解，企业盲目追求这种炫酷技术并不可取。同时，这种盲目行为对于希望用微服务来有效解决问题的公司很不利。不是说任何特定的技术都是缺乏实际价值的，如微服务、Kubernetes、Lambda函数之类的新技术是否被企业采纳，也许都取决于错误的理由。很多时候，企业可能只因为它比较流行就使用这些术语，却没有真正让它的技术优势在棘手的问题上发挥作用，或者提供切实可行的解决方案。从某种程度上说，它夸大了技术的实际作用，还给架构的合理选择和使用制造了障碍，这对于其他技术来说也很不公平。因此，虹科想通过这篇文章来为大家一一澄清对于微服务所流传的五大误解。
微服务简介
微服务作为基础设施构建块提供了诸如服务解耦、数据存储自治、小型化开发和测试设置，缩短应用程序上线时间的优势。容器及其编排工具的可用性也提高了微服务的采用。每个微服务都是围绕一个特定的业务上下文——一个目标、焦点或问题领域。这些模块化的服务通过 API 进行通信，以便在应用程序中执行它们自己的功能。微服务应用程序的敏捷性、孤立性和专注性带来了显著的优势。包括：
- 团队授权：小型独立团队可以快速部署代码，以非常敏捷的速度适应不断变化的要求； 灵活性：每个服务都可以使用最适合其独特需求的技术来构建；
- 可重用性：简单和模块化的代码是可重用的，可以应用于多种目的，以实现更快的开发；
- 隔离：隔离确保应用程序组件可单独操作和可扩展，并提供故障隔离，以防止微服务的 故障相互影响。
误解一：微服务可以解决所有问题
老话常说：“当企业只有一把锤子的时候，一切看起来都像钉子”。如果微服务能帮企业解决实际难题，那自然好。但许多企业可能认为：
1.只要有应用场景，那么微服务就是解决方案。Redis企业版数据库的合作伙伴解决方案架构师Lars Rosenquist建议：“首先，企业要搞清什么是微服务；然后，企业需要了解自己的应用架构出了什么问题；最后，才对两者进行匹配进行方案制定。但是很少人愿意真的这么做。”
2.多数技术只能解决特定企业规模的具体问题。Lars Rosenquist解释说："如果是像Netflix这样的大公司，企业的应用消耗了三分之一的互联网流量，那就必须进行架构，才能使技术发挥作用。但如果企业是一家运营规模较小的公司，比如一家本地银行，那就不需要了。人们经常是在为他们想要解决的而不一定是真正存在的问题进行优化。”
3.大多数用例都不需要微服务。编程专家建议：要尽量避免 "庞大的单体架构不好，庞大的单体架构是旧的解决方案"的心态，反之，企业在采用微服务方法之前，就应摒弃这样的错误认知。
二：微服务降低了复杂性
其实，微服务架构几乎都会增加复杂性。若不加以控制，它甚至还会变成一个分布式系统，使得架构更加混乱。因为：
1.微服务并不能解决系统设计问题。iDIA计算公司的软件开发顾问George Dinwiddie说：“如果企业不能创建一个具有高内聚低耦合的单体设计，那它很难把微服务做好。”
正如康威定律所言，先从一个单体开始，然后企业在增添开发人员时再去提取服务。Rosenquist认为："对于一个单体应用程序，它包含了所有的逻辑、通信和复杂性。通过微服务，企业却能打破这一常规。因为像通信模式之类的现在都属于企业基础设施的一部分。”
2.微服务不能消除复杂性。微服务只是把复杂性移到了不同的抽象层，并没有真正让它消失。比方说，企业如果使两个应用程序组件处于同一个应用程序、同一个进程，甚至在同一个CPU中相互通信，那这个应用程序的速度一定是非常快的。但是对于微服务，这些应用组件被放在了不同机器上，它们之间相隔了一个网络，一整套基础设施，甚至可能是在不同的云中。这对于通信、故障模式及性能评估方面都会是非常大的挑战。”
使用虹科Redis企业版数据库，可以让管理复杂性变得更容易!但不要忽视复杂性是仍然存在的。
3.架构的复杂导致调试应用程序更加困难。为了更好地管理这种复杂性，还需要确保企业的监控和可观察性工作做到位。尽管微服务方法可使企业的代码不再那么复杂，但 Rosenquist指出：“当要部署或管理它时，也许不再那么容易，企业现在并非只有一个而是有多个应用程序需要调试。这些应用程序在多个实例上运行，而这些实例也在整个架构中实现负载均衡。所有的这些通常都比使用单一的应用程序更为复杂。因此，要想实现成功部署，则需加强类似于日志聚合和可观察性之类事件的关注。”
4.不太复杂的代码并不一定能转化为不太复杂的系统。Redis的开发领导者William Johnston指出"从代码的角度来看，单个服务可能更好理解，但企业用微服务创建的系统的复杂性会比单体复杂得多。"特别是在已经超负荷工作的小团队中，这也许意味着需要花费更多的开发时间。虽然能促使开发人员去学习应用领域和整个系统，但对于时间期限紧迫或缺乏技术经验的团队来说，微服务不可能“慢慢来”！因为微服务作为一种相当不同的操作方式，技术要求十分高。从长远看，整个系统的耦合度降低可以让重构更容易，但这也需付出很高的代价，并且开发人员的生产力可能会大幅下降，还可能影响对质量的保证。基于此，一个微服务依赖于这么多关系，它的测试难上加难。
Redis企业版数据库微服务可通过快速和灵活的数据模型降低复杂性
备注：康威定律是马尔文康威1967提出的：“设计系统的架构受制于产生这些设计的组织的沟通结构。”通俗的来讲：产品必然是其（人员）组织沟通结构的缩影。
误解三：一种架构可以适用于一切
一种架构难以应用于企业的所有场景：
1.企业的旧应用程序可能不支持这些架构类型的模式。企业也不应该认为自己可以立即开始重构旧的应用程序，要区分单体、微服务和函数。一个函数只做一件事，它们属于事件驱动型，是为特定的架构服务的。但在企业流程方面，如果企业分解掉所有的系统，最终会有一千个组件，企业也就不再具有优势。
2.最好的方法取决于具体的使用情况。举个例子，一家银行很可能有相当多的单体系统。但为企业移动银行应用提供动力的微服务应用大约占到了50%-60%，其余的才是函数。因此，一家企业在架构方面应用场景是多样化的。
无论企业使用的是什么软件架构或模式，一个优秀的工程团队都要学会找到最有效的方法。
误解四：微服务主要是一种技术
1.实际上微服务解决的是一个业务或组织的可扩展性问题。Johnston指出："微服务解决的是一个技术问题，如果未达到这个目标，那就是浪费时间。很多人甚至是部分大型企业启动一个新的应用程序时，都认为他们需要从分离领域的方式及微服务开始，但如果企业对业务领域没有一个明确的定义，就不该从微服务开始。”
再一次引用康威定律，企业软件环境中和组织整体中的通信模式是相似的。
Rosenquist认为："假设企业想从一个单体架构转换到一个微服务架构，应先建立在本身的组织架构上。比如，将团队分开，确保每个微服务属于其中一个团队，这其实是一个管理问题，而非一个技术挑战。”
2.应当确保每个人都理解微服务的含义，以及该技术解决业务问题的方式。不同部门对微服务的本质往往有不同的看法。采用微服务架构是否能获得优势取决于这个问题的大小以及采用该技术的团队本身。
误解五：微服务允许团队使用他们喜欢的技术
这其实并不完全是一个误解，因为对团队来说，使用不同的平台并不总是一个好主意。
Johnston认为：“人们普遍认为可以使用他们喜欢的语言、工具和平台，这是微服务的一个优势。但如果企业团队很大，甚至有分布在世界各地，比如，一些团队可能擅长.NET，而另一些则擅长Java。那么对于他们特定服务的业务领域，使用某种特定技术可能对他们有利。”然而，Johnston提醒说：“对额外环境的开发是以增加系统的复杂性为代价的，企业架构师也需要了解系统的复杂性。" Rosenquist建议："企业可以为每个微服务选择不同的技术，但如果企业有500个微服务，仅使用5种技术会更好而不是500种不同的技术。”当然，这些都是例子，没有一个放之四海而皆准的方法，企业应当在管理和加大开发复杂性之间找到平衡点。
关于微服务的误解众多
以上是我们分享给大家的关于微服务流传较广的误解，但并不仅限于此。虹科云科技在这里也为大家整理了一些其他关于微服务的误解：
1.微服务能加速业务。Johnston建议："由于网络跳转的增加，微服务会引发速度下降。企业必须接受最终的一致性，但在其他类型的应用程序中企业可以不需要这么做。”
2.微服务实际上是很小的。技术咨询公司Archium的联合创始人Graham Le提到：“不要被微服务中的【微】所迷惑。微服务应该比单体小，但最理想的是，一个服务能覆盖一个中等规模的领域。小只是一个相对的术语；但重点不是让他们变得非常小。”
3.每种客户端都需要对应一个微服务。咨询公司Blue Herring的DevOps架构师Mark W. Schumann表示"这种想法是错误的，但他们一直在这样认为！与之相反，应该考虑每个资源对应一个微服务"。
Redis企业版可以解决的微服务问题
作为一个多租户解决方案，Redis Enterprise 企业数据库在微服务之间隔离数据。最重要的是，它允许用户对数据库进行调优，以在性能和数据一致性/持久性之间保持权衡。Redis企业版数据库还可用于将实时性能扩展到缓存之外的一些微服务用例，如；服务内通信和事件源，也通常被用作支持单个微服务的轻量级数据库。Redis企业版数据库在微服务方面主要具有以下优势，为客户提供最全面的解决方案：
1.降低系统复杂性
每个Redis 企业版数据库缓存的各个方面都可以为每个微服务定制，提供简化的管理，以减少微服务架构带来的操作复杂性。
2.提供实时速度更快的微服务
所有的网络延迟都会降低应用程序的性能。Redis企业版数据库提供了一种方法来收回服务
间通信损失的大部分时间，具有数据查询和消息传递的亚毫秒性能，让微服务应用速度更快。
3.多租户支持
多租户违背了微服务完全隔离单个应用组件的做法，因此，系统经常遇到争夺资源的挑战，个别服务可能过度消耗其他微服务共享的资源。用户可以在Redis企业版数据库安装上为所有微服务部署多个数据库实例，而且数据在数据库之间保持隔离。Redis企业版数据库的内置机制通过触发重新分片或跨节点移动来平衡吞吐量/延迟，从而保护实例不受影响。
4.高可用性与自动故障检测
Redis企业版数据库的架构提供了自动故障检测和零停机时间扩展，对使用它的微服务完全透明。故障检测和故障转移可以在几秒钟内完成，并且不会丢失数据，高度可靠、随时可用。
5.原生 Kubernetes 容器编排和管理
用户可以在 Kubernetes 环境中把 Redis企业版数据库容器作为云原生数据库服务进行协调。
二者集成可以实现多种功能。
6.支持多种部署模式
无论用户的微服务是在私有云环境、企业内部还是在云中运行，Redis企业版数据库的灵活
部署选项都能让微服务尽可能地接近数据，并使用户可以完全控制它的数据。
推荐阅读：
《虹科分享 | 一起聊聊Redis企业版数据库与【微服务误解】那些事儿！》
下载【白皮书—《Redis Enterprise 如何用于微服务缓存》】或了解更多【Redis数据库解决方案】，欢迎关注我们或者评论交流！
虹科云科技，主要分享云计算、数据库、商业智能、数据可视化、高性能计算等相关知识、产品信息、应用案例及行业信息，为学习者传输前沿知识、为技术工程师解答专业问题、为企业找到最适合的云解决方案！