Monolithicapplication与微服务相反的另一个概念是传统的“Monolithicapplication”，它包含了所有需要的服务。而且各个服务功能模块具有很强的耦合性，即相互依赖，难以拆分和扩展。这里大家都写过单机程序，给大家举个栗子。当你第一次写代码的时候，你写的helloworld程序是一个单一的程序。一个程序包含所有功能，虽然helloworld功能很简单。单一应用程序的优点开发简单，功能都在单一程序中，便于软件设计和开发规划。易于部署，在分布式集群的复杂部署环境中不存在单一程序，降低了部署难度。易于测试，没有复杂的服务调用关系，所有内部调用方便测试。单体应用的缺点单体应用的缺点一开始并不是特别明显。项目初期，需求少，业务逻辑简单，写代码总是爽。噩梦是从业务的迭代更新和系统规模的不断扩大开始的。前期的兴奋没有了，取而代之的是无尽的软件维护和迭代更新的痛苦。单体架构因为单体应用就像一个大容器，很多服务都放在里面，而且都是密不可分的，这就导致应用必须以“应用”为单位进行扩展。当一个业务模块负载过高时，服务无法独立扩展，必须扩展整个应用（就是这么霸道），可能会造成额外的资源浪费。另外，由于服务之间的紧密度和相互依赖度高，单体应用会导致测试和升级困难，后期开发曲线可能急剧上升，开发难度大。相比之下，“微服务架构”可以解决这个问题。微服务微服务是协同工作的小型自治服务。?2014年，MartinFowler和JamesLewis共同提出微服务的概念，定义微服务是由单个Deploy以自动方式组成的小服务，使用HTTPAPI与其他服务进行通信。同时，该服务将使用最小规模的集中管理（如Docker）能力，服务可以用不同的编程语言和数据库组件来实现。「维基百科」?以之前的helloworld程序为例。假设你是helloworld公司的CTO（老板还缺人吗？会写代码的那种），假设你公司的helloworld业务遍布全球，你需要编写不同语言的helloworld版本分别输出英文、日文、法文、俄文……现在世界上有6000多种语言（奇怪的知识增加了）。有人会说，这并不容易。我只是使用switchcase语句来完成工作。同学们，别当真。我只是给你举个例子。现实中的业务要比helloworld复杂的多。好吧，让我们认为通过语言输出是一项庞大而复杂的工作。这时候我们就可以使用微服务架构了。架构图如下：ServiceArchitectureMicroservicesandSOA“Service-OrientedArchitecture”SOA（Service-OrientedArchitecture）听起来和微服务很像，但是SOA早期采用的是总线模型，与一定的技术栈强绑定例如：J2EE。这使得许多企业的遗留系统难以连接。切换时间太长，成本太高。令人生畏。另外，在实现SOA时会遇到很多问题，比如通信协议（如SOAP）的选择，第三方中间件如何选择，服务粒度如何确定等，也有一些指导原则来划分系统，但有很多是错误的。SOA并没有告诉你如何将一个单体应用拆分成微服务，所以你在实现SOA的时候会遇到很多问题。这些问题在微服务框架中得到了很好的解决，您可以将微服务架构视为一种特定的SOA方法。微服务架构必须划分很长时间。针对“单体应用”的上述缺点，将单个应用拆分成各种小的、相互关联的微服务。一个微服务完成一个相对单一的功能，并相互通信。保持独立和解耦，这就是微服务架构。微服务的优势与单体服务相比，微服务有很多优势。以下是一些主要优点。技术异质性。不同服务的内部开发技术可能不一致。可以用java开发helloworld服务A，用golang开发helloworld服务B，不用再争论世界上哪种语言最好。为不同的服务选择最合适的技术。系统的不同部分也可以使用不同的存储技术。比如服务A可以选择redis存储，服务B可以选择MySQL存储。这都是允许的。您的服务由您决定。隔离一个服务不可用不会导致另一个服务宕机，因为每个服务都是一个独立的自治系统。这不能在单体应用程序中完成。如果单体应用中的某个模块瘫痪，整个系统将不可用。当然，单体程序也可以将同一个程序部署在不同的机器上，实现备份。但是，也存在上面提到的资源浪费。如果一个具有巨大可扩展性的单体服务出现性能瓶颈，我们只能将软件作为一个整体进行扩展。真正影响性能的可能只是一个小模块，我们要付出升级整个应用的代价。这在微服务架构中得到了改进。只能扩展和升级那些影响性能的服务，所以对症下药效果非常好。简化部署如果你的服务是一个百万行代码的大单体服务，即使修改几行代码，重新编译整个应用显然是非常繁琐的，而且软件变更带来的不确定性非常高，而且影响软件部署量也很大。在微服务架构中，每个服务的部署都是独立的。如果出现问题，只会影响单个服务，可以快速回滚版本来解决。易于优化微服务架构中单个服务的代码量不是很大，所以当你需要重构或优化这部分服务时，会容易很多。毕竟代码量越小，代码变更的影响可控性就越大。微服务的缺点上面我们一直在强调微服务的好处。但是，微服务架构并不是万能的，不能解决所有问题。其实这也是微服务把单个应用拆分成很多小的分布式服务造成的。正所谓人多手杂，服务太多，管理不善，就会出现各种问题。为了解决微服务的不足，前人提出了以下几个概念。服务注册和发现微服务相互调用，完成整体业务功能。如何在众多微服务中找到正确的目标服务地址，就是所谓的“服务发现”功能。一种常见的做法是服务提供者在启动时将其地址报告给“服务注册中心”，称为“服务注册”。服务调用者“订阅”服务变更“通知”，动态接收服务注册中心推送的服务地址列表，以后可以直接发给他想找哪个服务。单个程序的服务发现、服务监控、监控、运维还好，大规模微服务架构的服务运维是一个很大的挑战。服务运维人员需要实时掌握服务的各种状态。最好有一个控制面板，可以看到服务的内存使用率、调用次数、健康状态等信息。这就需要我们有一套完整的服务监控体系，包括拓扑关系、监控（Metrics）、日志监控（Logging）、调用跟踪（Trace）、告警通知、健康检查等，做到防患于未然。服务容错任何服务都不能保证100%没有问题。生产环境复杂多变，服务运行过程中难免会出现各种故障（宕机、过载等）。尽快缩小影响范围，恢复正常服务。聪明的程序员引入了“熔断、隔离、限流降级、超时机制”等“服务容错”机制，保证服务持续可用。服务安全部分服务的敏感数据存在安全问题。“服务安全”就是对敏感服务采用安全认证机制。访问服务需要相应的身份验证和授权，以防止数据泄露的风险。安全是一个长期的话题，在微服务方面也有很多工作要做。说到服务治理，一般只有出现问题才需要“治理”。我们通常指的是环境治理和污染治理。微服务架构中的微服务越来越多，上面提到的问题也更加明显。为了解决上述微服务架构的缺陷“服务治理”而出现。如果微服务的问题非得靠公司的技术团队来解决，如果不是大公司有成熟的技术团队，估计会很头疼。幸运的是，有巨人可以借我们的肩膀，通过引入“微服务框架”来帮助我们完成服务治理。MicroserviceFramework介绍了一些业界比较成熟的微服务框架。Tars是基于腾讯内部微服务架构TAF（TotalApplicationFramework）多年实践成果的开源项目。只支持C++语言，目前在腾讯内部应用广泛。2017年开源，仅支持C++语言。源码：https://github.com/TarsCloud/Tars/TARS架构图|来源github.com/TarsCloud本名鹅厂TARS框架详细介绍PPT已下载，不想麻烦的同学自己去，之后我公众号”“完工学堂”回复“tars”即可获取。Dubbo是阿里巴巴开源的Java高性能卓越服务框架，让应用程序通过高性能RPC实现服务的输出和输入功能，并能与Spring框架无缝集成。ApacheDubbo|d?b??|是一个高性能、轻量级的开源JavaRPC框架，提供了三大核心能力：面向接口的远程方法调用、智能容错和负载均衡、自动服务注册和发现。2011年底开源，仅支持Java语言。官网：http://dubbo.apache.org/zh-cn/Dubbo架构图|图片来源dubbo.apache.orgMotan是新浪微博开源的Java框架。Motan已在微博平台得到广泛应用，每天完成近千亿次调用数百项服务。2016年开源，仅支持Java语言。官方指南：https://github.com/weibocom/motan/wiki/zh_userguideMotan框架|图片来源github.com/weibocom/motangRPC是Google开发的一款高性能、通用的开源RPC框架，主要开发由谷歌为移动应用设计，基于HTTP/2协议标准设计，基于ProtoBuf（ProtocolBuffers）序列化协议开发。它本身不是分布式的，所以需要进一步开发来实现上述框架的功能。2015年开源的跨语言RPC框架，支持多种语言。中文教程：https://doc.oschina.net/grpc?t=58008gRPC架构图|图片来源www.grpc.iothrift最初由Facebook开发，作为内部系统跨语言的高性能RPC框架，于2007年贡献给ApacheFund，成为Apache开源项目之一。和gRPC一样，Thrift也有自己的接口定义语言IDL，可以通过代码生成器为客户端和服务端生成各种编程语言的SDK代码，支持多种语言。节俭建筑|图片来源wikimedia微服务框架和RPC很多人对这两个概念有点困惑。上面我们提到了微服务框架。我们来看一下RPC的概念。什么是RPCRPC（RemoteProcedureCall）RemoteProcedureCall是一种计算机通讯协议。我们一般的程序调用都是本地程序内部的调用。RPC允许你像本地函数一样调用另一个程序的函数，这涉及网络通信和进程间通信，但你不需要知道实现细节。RPC框架会为你做底层实现屏蔽。RPC是一种服务器-客户端（Client/Server）模型，经典的实现是通过“发送请求-接受响应”进行信息交互的系统。两者的关系就是RPC和微服务框架的关系。“微服务框架”一般包括RPC的实现和一系列“服务治理”能力，是一套软件开发框架。我们可以基于这个框架实现自己的微服务，方便的使用微服务框架提供的“服务治理”和RPC能力，所以微服务框架也被一些人称为RPC框架。下一代微服务架构ServiceMesh（服务网格）被认为是下一代微服务架构。ServiceMesh并没有给我们带来新的功能。用于解决其他工具已经解决的服务网络调用和限流问题。、熔断和监控，不过这次是在CloudNativekubernetes环境下实现的。特性ServiceMesh具有以下特性：应用间通信的中间层轻量级网络代理应用无感知解耦应用重试/超时、监控、跟踪和服务发现目前两个流行的ServiceMesh开源软件都是[Istio](https://istio.io/)和[Linkerd](https://linkerd.io/)可以直接集成到kubernetes中，其中Linkerd已经成为云原生计算基金会CNCF（CloudNativeComputingFoundation）成员。WhyServiceMesh现有微服务架构已经解决的问题，为什么要用ServiceMesh？好问题。回答问题之前，先看看istio.io上关于servicemesh的解释。我认为它非常好，我复制了它：?随着服务网格的规模和复杂性的增长，它会变得更难理解和管理。它的要求可以包括发现、负载平衡、故障恢复、指标和监控。服务网格通常还具有更复杂的操作要求，例如A/B测试、金丝雀发布、速率限制、访问控制和端到端身份验证。使创建具有负载平衡、服务到服务身份验证、监视等功能的已部署服务网络变得容易，**服务代码中的代码更改很少或没有。**?尝试总结一下：随着微服务变得越来越复杂程度也越来越高，管理难度也越来越大。微服务架构虽然解决了“网络调用、限流、熔断、监控”等问题，但大多数框架和开源软件对原有业务的侵入性较大，即需要在其中集成相关的“服务治理”组件业务服务程序。服务网格之于微服务就像TCP/IP之于互联网。TCP/IP为网络通信提供了面向连接的、可靠的、基于字节流的基本通信功能。你不再需要关心底层的重传、Checksum、流量控制、拥塞控制。有了ServiceMesh，你就不用担心“服务治理”的细节问题，也不需要对服务做特别的改动。业务之外的所有功能都由ServiceMesh为您完成。它就像一个轻量级的网络代理，对应用程序是透明的，应用程序之间的所有流量都经过它，因此可以在服务网格中实现对应用程序流量的控制。服务网格架构|图片来自：Pattern：ServiceMesh写在最后。在IT世界中，没有一种技术是永恒的。微服务架构的演进就是一个例子，从单体程序到微服务架构，再到服务网格架构。我不知道下一次技术迭代是什么时候，但我可以肯定微服务架构会不断演进，IT人应该养成终身学习的习惯。当然，更重要的是要有对技术的热情，拥抱变化，接受新技术。当我看到新技术时，我很兴奋。心目中的OS厉害了，还能这么玩！，希望你也有这样的热情，而不仅仅是为了薪水而编程，这样生活才会更有乐趣。旧规则。感谢您阅读。文章的目的是分享对知识的理解。我会反复验证技术文章，最大程度保证准确性。如果文章中有明显的错误，欢迎大家指出。我们将通过讨论共同学习。
