简介近年来，软件设计的规模越来越大，业务需求越来越复杂。针对系统性能、高吞吐量、高稳定性、高扩展性等特点提出了更高的要求。可以说，业务需求是软件架构能力的第一驱动力。由于这些因素，软件架构思想和相关技术也在发生着巨大的变化。这些变化反映在软件架构行业，也就是我们开始听到越来越多的新词，比如：“分布式”、“SOA”、“微服务”、“中台”等概念。今天记录一下我学习微服务的过程，包括实现细节和个人对所有技术的理解。俗话说：好记性不如烂笔头，万一忘记了，以后可以翻翻看。当然，其中很多东西都是我自己的理解，里面的插图也是我自己画的，可能会有一些偏颇的地方。当然也希望有高手指正，不吝赐教，大家共同进步。架构发展史当今的科学技术可以说是日新月异，日新月异。与我们的软件设计行业相比，也在发生着很大的变化。业务越来越复杂，需求越来越大，越来越复杂，软件架构和部署规模也在发生翻天覆地的变化。作为软件架构的思想之一，“微服务架构”也在按照自己的规律在演进。接下来我们简单了解一下“微服务架构”发展的三个时期。这些只是个人理解。单体（Monolithic）单体应用时代：不管应用有多分层，它都是一个解决方案，或者一个项目。这里的“解决方案”和“项目”并不是我们在VisualStudio中使用的概念，最终的程序代码会运行在一个进程中。如图所示：优点：开发简单，集中管理，无分布式损耗，所有通信在系统进程内进行。缺点：难维护，难升级，耦合严重，无法应对高并发和大数据场景，无法快速迭代。只能使用相同的技术，很难用不同的语言或同一种语言的不同版本开发不同的模块。系统耦合性太强，如果其中一个模块出现问题，系统就会瘫痪，如果某个模块升级，整个系统就不得不停机维护。要上线，必须一起上线，互相等待，不能快速响应市场需求。集群的负担很重。如果要集群，只能集群整个系统，哪怕一个模块有压力。垂直拆分随着业务规模越来越大，系统设计也越来越复杂，大系统开始对业务进行垂直拆分。比如：有专门做产品闪购的部门，有专门做生鲜的部门，有专门做超市的部门等等。当然这个自然是按部门划分的，也有按业务划分的系统划分需要。如图：优点：垂直拆分，系统独立部署和维护，每个系统在自己的进程中执行，分而治之。缺点：拆分越多，存储越复杂，系统之间重复的东西也越多。单一系统仍然是单一模型。分布式服务随着业务系统越来越庞大，软件系统的设计也越来越复杂。为了避免过于复杂的业务需求，我们开始对业务系统进行垂直拆分，形成多个独立的业务系统。如果多个系统需要相互通信，可以通过跨进程技术来完成通信。但垂直拆分也导致产生大量重复的代码和模块，如用户模块、日志模块、支付模块、认证授权模块等，这些分散的代码也给系统维护和升级带来困难。我们重新划分了业务，对接和服务了独立的模块，提高了复用性。这时候，我们开始进入分布式服务时代。（分布式的第一要务是不要分布式）如图：优点：进程独立部署，进程独立运行，独立演进。服务可以实现高内聚和低耦合。独立开发维护，业务解耦，业务系统和分布式服务均独立演进。分布式管理增强隔离一系列服务组装成一个系统，无需重复构建，模块和代码可以复用。缺点：数据一致性（多个服务完成一个任务）和系统可用性（集群）成为问题。数据库也被拆分维护、设计，架构成本增加。调试和纠错都比较困难。网络传输分布式损耗成本不适合高并发和大数据环境微服务架构微服务出现时分布式架构已经非常成熟，架构中的各种问题都已经有了非常成熟的解决方案。对于现在的业务系统来说，分布式架构已经成为一种常规手段，这时候，微服务就出现了。微服务架构是一种利用分布式服务拆分业务逻辑，完成解耦的架构模式（architecturestyle）。微服务必须是一种分布式。分布式技术成熟后，再以分布式系统作为解耦的手段来构建系统。体量开始缩小，从之前的几个大服务变成了多个独立运行的原子服务。如图所示：微服务最重要的特性是：可用性：描述了系统在一段时间内提供有用资源的能力，从而减少停机时间并保持其服务的高可用性。可扩展性：能够根据需要在系统中动态增减资源，是水平或垂直扩展的一种专门实现。集群（负载均衡）可以解决系统的高可用和伸缩特性。优点：单个模块可以用不同的语言开发，也可以用同一种语言的不同版本开发。系统耦合度低，各模块分而治之，独立部署，独立发布，独立维护。可以更快的响应市场的需求，更符合敏捷开发。集群策略可以针对不同的模块，哪里有问题，哪里就有解决。缺点：开发难度较大，系统结构较复杂。运行效率低，网络调用成本很高。SOAService-OrientedArchitecture面向服务的体系结构：它是一种组件模型，它将应用程序的不同功能单元（称为服务）拆分并通过定义良好的接口和协议将它们连接起来。如图：微服务架构的发展历程。我们要解决微服务的高可用和可扩展性这两个问题，自然会想到通过集群来实现。这个想法没有错。如果我们实现服务集群，那么会出现另外两个问题，这也导致微服务架构的开发版本存在差异。第一个：服务发现的问题，调用者如何发现服务，我们怎么知道什么时候有新服务，我们怎么知道一个服务实例是否下线，服务的发现很重要，这个是基本问题，第一个问题不解决，第二个问题就没有办法实现；第二：如何调用服务，如何管理这么多服务实例。有那么多集群实例，那么就有那么多服务实例，我们怎么调用这些服务呢？多个服务调用之间有什么关系？因为这些问题，我们来看看微服务架构的三个版本是如何解决的。集中代理-NginxV1.0（服务注册/服务发现-手动）服务发现，手动修改配置文件，重启。负载均衡、轮训、权重、哈希等。找不到新服务需要手动配置，自动检测服务断开。客户端的实现非常简单，不需要额外的代码，简单高效。客户端嵌入-ConsulV2.0（服务注册/服务发现-自动-服务治理）服务注册与发现，动态增加，自动完成。健康检查，可以检查损坏的服务，移除服务，自动完成。对于负载均衡，Consul返回所有活跃的服务实例，客户端自己实现负载均衡。功能强大，自动发现-自动下线，客户端集成比较复杂，负载均衡在客户端实现。ServiceMesh-ServiceMeshV3.0-不成熟技术，华为+唯品会，IstioSideCar服务管理服务实例注册与发现，服务实例治理与调用。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.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等技术栈的应用，并提供一个可以应用于Javascript、Node.js的Rest接口。它使日志收集易于使用，并且不需要太多的技术细节和配置。以往我们多使用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/MicroserviceArchitecture-分布式锁和分布式锁的解决方案很多。我这里罗列一些，我会在以后的实践中去落实这些技术点。Consul可以实现分布式锁Redis可以实现分布式锁，推荐。ZooKeeper可以实现分布式锁，数据库可以实现分布式锁。微服务架构——分布式事务分布式事务的实现方式也有很多，以后好好学习吧。2PC（两阶段提交协议，强一致性，无可用性）3PCTCC（Try-Confirm-Cancel）本地消息表，推荐RabbitMQSaga模式本地消息表：MQ分布式事务-本地消息表-基于消息的一致性。上游传递消息下游获取消息上游传递稳定下游接受稳定微服务架构-容器化Docker是一个开源的应用容器引擎，可以将应用和依赖包打包成一个可移植的镜像，然后发布到任何流行的Linux上也可以虚拟化和Windows机器。Docker使用客户端-服务器(C/S)架构模式并使用远程API来管理和创建Docker容器。Docker容器是通过Docker镜像创建的。容器和镜像的关系类似于面向对象编程中的对象和类。Docker使用C/S架构的Dockerdaemon作为服务端，接受客户的请求并处理这些请求（创建、运行、分发容器）。客户端和服务端可以运行在同一台机器上，也可以通过socket或RESTfulAPI进行通信。Docker守护进程一般运行在宿主机host的后台，等待接收来自客户端的消息。Docker客户端为用户提供了一系列可执行命令，用户通过这些命令与Docker守护进程进行交互。图为：微服务架构——容器编排Kubernetes是谷歌开源的容器编排引擎，支持自动化部署、大规模扩展和应用容器管理。在生产环境中部署应用程序时，通常会部署应用程序的多个实例来负载平衡应用程序请求。在Kubernetes中，我们可以创建多个容器，在每个容器中运行一个应用实例，然后使用内置的负载均衡策略来实现对这组应用实例的管理、发现和访问，而这些细节不需要操作和维护。人员执行复杂的手动配置和处理。Kubernetes也可以理解为Docker的编排容器。它是管理应用程序整个生命周期的工具。非常方便的创建应用/部署，为应用提供服务，扩缩容，更新，可以实现故障的自愈。官网：https://kubernetes.io/docs/home/微服务架构-CI/CDJenkins是一款开源的持续集成（CI）工具，提供友好的操作界面，主要用于持续自动构建/测试软件项目，监控外部任务的运行。官网：https://www.jenkins.io/结束语好了，今天就到这里吧，今天还是写了很多东西，今天不写别的，简单记录下相关的技术栈。仔细研究每一项技术，可能是每一项技术，也可能是作为一个项目，可能包括很多其他的技术，到时候再决定。每天进步一点，加油。
