近年来，软件设计的规模越来越大，业务需求也越来越复杂。对系统性能、高吞吐量、高稳定性、高扩展性提出了更高的要求。图片来自Pexels。可以说，业务需求是软件架构能力的第一驱动力。由于这些因素，软件架构思想和相关技术也在发生着巨大的变化。这些变化反映在软件架构行业，也就是我们开始听到越来越多的新词，比如：“分布式”、“SOA”、“微服务”、“中台”等概念。今天记录一下我学习微服务的过程，包括实现细节和个人对所有技术的理解。俗话说：好记性不如烂笔头，万一忘记了，以后可以翻翻看。当然，其中很多东西都是我自己的理解，里面的插图也是我自己画的，可能会有一些偏颇的地方。当然也希望有高手指正，让大家共同进步。架构发展史当今的科学技术可以说是日新月异，日新月异。与我们的软件设计行业相比，也在发生着很大的变化。业务越来越复杂，需求越来越大，越来越复杂，软件架构和部署规模也在发生翻天覆地的变化。“微服务架构”作为软件架构思想之一，也在按照自身的规律不断演进。接下来，我们简单了解一下“微服务架构”的三个时期的开发经历。这些只是个人理解。单体（Monolithic）单体应用时代：不管应用有多分层，它都是一个解决方案，或者一个项目。这里的“解决方案”和“项目”并不是我们在VisualStudio中使用的概念，最终的程序代码会运行在一个进程中。如图：优点：开发简单，集中管理，无分布式损耗，所有通信在系统进程内。缺点：难维护，难升级，耦合严重，无法应对高并发和大数据场景，无法快速迭代。垂直拆分随着业务规模越来越大，系统设计也越来越复杂，大系统开始对业务进行垂直拆分。比如：有专门做产品闪购的部门，有专门做生鲜的部门，有专门做超市的部门等等。当然这个自然是按部门划分的，也有按业务划分的系统划分需要。如图：优点：垂直拆分，系统独立部署和维护，每个系统在自己的进程中执行，分而治之。缺点：拆分越多，存储越复杂，系统之间重复的东西也越多。单一系统仍然是单一模型。分布式服务随着业务系统越来越庞大，软件系统的设计也越来越复杂。为了避免过于复杂的业务需求，我们开始对业务系统进行垂直拆分，形成多个独立的业务系统。如果多个系统需要相互通信，可以通过跨进程技术来完成通信。但垂直拆分也导致产生大量重复的代码和模块，如用户模块、日志模块、支付模块、认证授权模块等，这些分散的代码也给系统维护和升级带来困难。我们重新划分了业务，对接和服务了独立的模块，提高了复用性。这时候，我们开始进入分布式服务时代。（分布式的第一要务是不要分布式）如图：优点：进程独立部署，进程独立运行，独立演进。服务可以实现高内聚和低耦合。独立开发维护，业务解耦，业务系统和分布式服务均独立演进。分布式管理。增强隔离。一系列服务组装成一个系统，无需重复构建，模块和代码可以复用。缺点：数据一致性（多个服务完成一个任务）和系统可用性（集群）成为问题。数据库也被拆分了。维护、设计和架构成本增加，调试和纠错更加困难。网络传输分布式损耗成本。不适合高并发、大数据的环境。微服务架构在微服务出现的时候，分布式架构已经非常成熟，针对架构中的各种问题也已经有了成熟的解决方案。对于现在的业务系统来说，分布式架构已经成为一种常规的方式。这时候微服务就出现了。微服务架构是一种利用分布式服务拆分业务逻辑，完成解耦的架构模式（architecturestyle）。微服务必须是一种分布式。分布式技术成熟后，再以分布式系统作为解耦的手段来架构系统。因为拆分的服务很细，服务的数量开始增加，服务的体量开始缩小。从之前的几个大服务，转变为多个独立的、原子的服务。如图所示：微服务最重要的特性是：可用性：描述了系统在一段时间内提供有用资源的能力，从而减少停机时间并保持其服务的高可用性。可扩展性：能够根据需要在系统中动态增减资源，是水平或垂直扩展的一种专门实现。集群（负载均衡）可以解决系统的高可用和伸缩特性。SOAService-OrientedArchitecture面向服务的体系结构：它是一种组件模型，它将应用程序的不同功能单元（称为服务）拆分并通过定义良好的接口和协议将它们连接起来。如图：微服务架构的发展历程。我们要解决微服务的高可用和可扩展性这两个问题，自然会想到通过集群来实现。这个想法没有错。如果我们实现服务集群，那么会出现另外两个问题，这也导致微服务架构的开发版本存在差异。第一个：服务发现的问题，调用者如何发现服务，我们怎么知道什么时候有新服务，我们怎么知道一个服务实例是否下线，服务的发现很重要，这个是基本问题，第一个问题不解决，第二个问题就没有办法实现。第二：如何调用服务，如何管理这么多服务实例。有那么多集群实例，那么就有那么多服务实例，我们怎么调用这些服务呢？多个服务调用之间有什么关系？因为这些问题，我们来看看微服务架构的三个版本是如何解决的。①集中代理：Nginx（V1.0版本（服务注册/服务发现----手动））如上图：服务发现，手动修改配置文件，重启。负载均衡、轮训、权重、哈希等。找不到新服务需要手动配置，自动检测服务断开。客户端的实现非常简单，不需要额外的代码，简单高效。②客户端嵌入：Consul（V2.0版本（服务注册/服务发现—自动—服务治理））如上图：服务注册与发现、动态添加、自动补全。健康检查，可以检查损坏的服务，移除服务，自动完成。负载均衡，Consul返回所有活跃的服务实例，客户端自己实现负载均衡。功能强大，自动发现-自动下线，客户端集成比较复杂，负载均衡在客户端实现。③ServiceMesh：ServiceMesh（V3.0---不成熟技术，华为+唯品会，lstio）SideCar服务管理服务实例注册和发现，服务实例治理和调用。ServiceMesh的ControlPlan管理着所有的SideCars。这个技术我就不说了，网上有很多资料，这个技术目前还不是很成熟，使用范围也不是很广，只有一些大公司用过，比如：微软和很快。微服务架构必备的技术栈微服务是一种软件设计和架构思维。当然，其中也包含解决当前重要任务的相关技术点。学习微服务，不能光说说，一定要在具体的技术栈上去实现。现在使用的技术体系有两种，一种是Java，一种是Net。我们不废话了。我是一名软件架构师，使用微软的相关技术栈。当然，使用的“微服务”架构技术栈也是微软的。.今天我就罗列一下相关“微服务架构”中用到的技术栈。还要说明一下，微服务架构中的很多技术与开发语言无关，既可以在.Net平台上使用，也可以在Java平台上使用。未来，我们将一步一步对每一项技术进行深入研究。①服务通信WebService、WCF、WebAPI，甚至ASHX、ASPX，这些都是微软自家的技术体系，没啥好说的：主动触发数据序列化，跨平台跨语言传输Http，穿透防火墙②进程通信NetRemoting：Net平台主管岗位不支持跨平台。gRPC：高性能、开源、通用的RPC框架，面向服务端和移动端，基于HTTP/2设计，推荐。③API网关服务（Ocelot）API网关：是暴露在系统外部的访问入口。这家伙有点像代理访问，就像一个公司的看门人，负责寻址、限制访问、安全检查、位置引导等功能。Ocelot是一个使用.NETCore实现的开源API网关。它具有强大的功能，包括：路由、请求聚合、服务发现、认证、身份验证、限流和断路器。内置负载均衡器与ServiceFabric和ButterflyTracing集成。这些功能只需要简单的配置即可完成。如图：官网：https://ocelot.readthedocs.io/en/latest/index.html④Authentication&Authorization如今应用开发层出不穷，基于浏览器的web应用，基于微信的公众号，小程序、基于iOS、Android的App、基于Windows的桌面应用和UWP应用等等，如此多的应用类型给应用开发带来了挑战。除了单独实现各个应用之外，我们还需要考虑应用之间的交互和通用模块的细化。其中，身份认证和授权是各自的应??用。一个重要的部分。现在的互联网对信息安全的要求非常严格，统一的身份认证和授权非常重要。IdentityServer4就是这样一个框架。IdentityServer4是为ASP.NETCORE量身定制的认证授权中间件，实现了OpenIdConnect和OAuth2.0协议。项目地址：https://github.com/IdentityServer/IdentityServer4⑤瞬态故障处理Polly是一个强大的类库，Polly是一个.NET弹性和瞬态故障处理库，可以让我们使用非常流畅和线程安全的方式来执行诸如重试、断路、超时、故障恢复等策略。Polly是为.NET4.0、.NET4.5、.NETStandard1.1和.NETCore实现的。该项目的作者现已成为.NET基金会的成员。该项目一直在不断迭代和更新。你应得的。项目地址：https://github.com/App-vNext/Polly⑥分布式跟踪随着微服务架构的普及，微服务架构下的一些问题会越来越突出，比如一个请求会涉及多个服务，服务本身也可能依赖其他服务，整个请求路径形成网状调用链。但是，一旦整个调用链的某个节点出现异常，就会影响到整个调用链的稳定性，所以你会深深的感觉到“银弹”这个词并不存在，每种架构都有它的优点和缺点。面对上述情况，我们需要一些能够帮助理解系统行为和分析性能问题的工具，以便在出现故障时能够快速定位并解决问题。这时候，APM（ApplicationPerformanceManagement）工具就要登场了。项目地址：https://github.com/SkyAPM/SkyAPM-dotnet⑦分布式日志一般我们需要进行日志分析的场景：直接在日志文件中grep和awk就可以得到我们想要的信息。但是，在日志多且复杂的大规模场景下，这种方式效率低下，问题包括日志过多如何归档、文本搜索太慢怎么办、多维度查询等。需要集中管理日志，在所有服务器上进行日志收集和聚合。一种常见的解决方案是建立一个集中的日志收集系统，统一收集、管理和访问所有节点上的日志。大型系统通常具有分布式部署架构。不同的服务模块部署在不同的服务器上。当出现问题时，大多数情况下，需要根据问题暴露的关键信息来定位具体的服务器和服务模块，并构建一套集中的日志系统，可以提高定位问题的效率。Exceptionless：是一个开源的实时日志采集框架，可应用于基于ASP.NET、ASP.NETCore、WebApi、WebForms、WPF、Console、MVC等技术栈的应用，并提供了一个Rest接口可以在Javascript、Node.js中应用。它使日志收集易于使用，并且不需要太多的技术细节和配置。以往我们多使用Log4net、Nlog等框架进行日志采集。当应用变得复杂和集群时，传统的方法可能不太适用，因为收集各种日志并进行分析会变得麻烦和浪费时间。现在Exceptionless团队为我们提供了一个更好的框架来做到这一点。我认为这是非常伟大和有意义的，感谢他们。官网：http://exceptionless.com/GitHub：https://github.com/exceptionless/ExceptionlessELK：是三个开源软件的缩写，分别是：Elasticsearch、Logstash和Kibana，都是开源软件。但是现在有一个新的Beats，它是一个轻量级的日志收集和处理工具（Agent）。Beats占用资源少，适合收集各台服务器上的日志，然后传输到Logstash。这个工具也是官方推荐的。目前由于原有ELKStack成员加入了Beats工具，所以更名为ElasticStack，推荐使用。⑧分布式配置中心阿波罗（Apollo）是携程框架部开发的配置管理平台。它可以集中管理不同环境和不同应用程序集群的配置。配置修改后，可实时推送至应用端，并具有标准化的权限和流程。治理等特点。服务器基于SpringBoot和SpringCloud开发，打包后直接运行，无需额外安装Tomcat等应用容器。Java客户端不依赖任何框架，可以运行在所有的Java运行环境中，对Spring环境也有很好的支持。.Net客户端不依赖于任何框架，可以运行在所有.Net运行环境中。项目地址：https://github.com/ctripcorp/apollo/分布式锁的解决方案有很多，我这里列举一些：Consul可以实现分布式锁Redis可以实现分布式锁，分布式锁推荐Zookeeper分布式锁数据库可以实现分布式锁⑩分布式事务有多种实现方式：2PC（两阶段提交协议，强一致性，无可用性）3PCTCC（Try-Confirm-Cancel）本地消息表，推荐RabbitMQSaga模式本地消息表：MQ分布式事务——本地消息表——基于消息的一致性。上游传递消息下游获取消息上游传递稳定性下游接受稳定性?ContainerizedDocker是一个开源的应用容器引擎，可以将应用和依赖包打包成一个可移植的镜像，然后发布到任何流行的Linux和Windows上也可以实现虚拟化机器。Docker使用客户端-服务器(C/S)架构模式并使用远程API来管理和创建Docker容器。Docker容器是从Docker映像创建的。容器和镜像的关系类似于面向对象编程中的对象和类。Docker使用C/S架构的Dockerdaemon作为服务端，接受客户的请求并处理这些请求（创建、运行、分发容器）。客户端和服务端可以运行在同一台机器上，也可以通过Socket或RESTfulAPI进行通信。Docker守护进程一般运行在宿主机host的后台，等待接收来自客户端的消息。Docker客户端为用户提供一系列可执行命令，用户通过这些命令与Docker守护进程进行交互。如图：?ContainerOrchestrationKubernetes是Google开源的容器编排引擎，支持自动化部署、大规模扩展、应用容器管理。在生产环境中部署应用程序时，通常会部署应用程序的多个实例来负载平衡应用程序请求。在Kubernetes中，我们可以创建多个容器，在每个容器中运行一个应用实例，然后使用内置的负载均衡策略来实现对这组应用实例的管理、发现和访问，而这些细节不需要操作和维护。人员执行复杂的手动配置和处理。Kubernetes也可以理解为Docker的编排容器。它是管理应用程序整个生命周期的工具。非常方便的创建应用/部署，为应用提供服务，扩缩容，更新，可以实现故障的自愈。中文社区：http://docs.kubernetes.org.cn/官网：https://kubernetes.io/docs/home/?CI/CDJenkins是一款开源的持续集成（CI）工具，界面友好。用于软件项目的连续自动构建/测试和监控外部任务的运行。官网：http://www.jenkins.org.cn/结语好了，今天就分享到这里吧。别的不说，简单记录一下相关的技术栈。以后有空的时候，我会认真研究每一项技术。作者：可可可编辑：陶佳龙来源：https://www.cnblogs.com/PatrickLiu/
