做个网站的费用,百度免费网站如何建设,南京网站设计哪家好,游戏设计需要学什么专业一、简介 这些年软件的设计规模越来越庞大#xff0c;业务需求也越来越复杂#xff0c;针对系统的性能、高吞吐率、高稳定性、高扩展等特性提出了更高的要求。可以说业务需求是软件架构能力的第一推动力#xff0c;由于这些因素导致了软件架构思想和相关技术也在发生… 一、简介 这些年软件的设计规模越来越庞大业务需求也越来越复杂针对系统的性能、高吞吐率、高稳定性、高扩展等特性提出了更高的要求。可以说业务需求是软件架构能力的第一推动力由于这些因素导致了软件架构思想和相关技术也在发生着巨变。这些变化反应在软件架构行业里就是我们开始越来越多的听到了很多新的词汇比如“分布式”、“SOA”、“微服务”、“中台”等概念。 今天我就把我学习微服务的过程记录下来包括所有技术的实现细节和个人的理解。俗话说好记性不如烂笔头以防自己忘记以后可以查询。当然这些东西有很多东西都是自己的理解里面的插图也是自己画的可能会有一些有失偏颇的地方当然希望有高手可以指正不灵赐教大家共同进步。二、架构发展历程 现在的科学技术可以说是日新月异发展迅速。相对于我们软件设计行业也在发生着巨变业务越来越复杂需求越来越庞大、繁杂软件架构和部署的规模也发生着翻天覆地的变化作为软件架构思想之一的“微服务架构”也在按着自己的规律进化着接下来我们就简单的了解一下“微服务架构”发展经历的三个时期这些只是个人理解。 1、单体架构Monolithic 单体应用时代应用程序无论如何分层都是一个解决方案或者说都是一个项目这里的“解决方案”和“项目”不是我们使用的 Visual Studio里面的概念最终的程序代码都会在一个进程里运行。 如图 优点开发简单集中管理没有分布式的损耗都是系统进程内的通信。 缺点不好维护升级困难耦合严重无法应付高并发和大数据场景无法快捷迭代。 1、只能采用同一种技术很难用不同的语言或者相同语言不同版本开发不同模块。 2、系统耦合性太强其中一个模块有问题这个系统就会瘫痪一个模块升级整个系统就得停机维护。 3、要上线必须一起上线互相等待无法快速相应市场需求。 4、集群负担大如果想要集群只能对整个系统进行集群即使一个模块有压力。 2、垂直拆分 随着业务规模的越来越庞大系统设计就越来越复杂大的系统就开始进行业务的垂直拆分。比如有专门做商品秒杀的部门有专门做生鲜商品的部门有专门做超市的部门等等当然这是根据部门天生划分的也有根据业务需求进行系统划分的。 如图 优点垂直拆分系统独立部署和维护每个系统在自己进程内执行分而治之。 缺点拆分越多存储越复杂系统间重复的东西也越多单个系统还是单体模式。 3、分布式服务 随着业务系统的越来越庞大软件系统设计起来越来越复杂。为了避免过度复杂的业务需求开始对业务系统的进行垂直拆分形成多个独立的业务系统如果多个系统之间要通信可以通过跨进程的技术完成通讯。但是垂直拆分也导致了大量重复代码、重复模块的产生比如用户模块、日志模块、支付模块、认证授权模块等这样分散的代码也给系统的维护和升级带来了困难。我们对业务重新划分把独立的模块接口化、服务化提高重用这个时候我们就开始进入了分布式服务的时代。分布式的第一要务就是不要分布式 如图 优点 1、独立进程部署独立进程运行独立演化。服务之间可以做到高内聚低耦合。 2、独立开发和维护业务解耦无论是业务系统还是分布式服务都独立演化。 3、分布式管理 4、隔离性增强 5、由一系列服务组装成系统不用重复建设模块、代码可以复用。 缺点 1、数据一致性多服务完成一个任务和系统的可用性集群成为问题 2、数据库也进行了拆分。 3、维护、设计、架构成本增加调试、纠错更难。 4、网络传输分布式损耗成本 5、不适合高并发和大数据的环境。 4、微服务架构 微服务的出现时分布式架构已经很成熟了架构中各种问题已经有了很成熟的解决方案对于现在的业务系统来说分布式架构已经变成了一种常规手段这个时候微服务就出现了。微服务架构是一个用分布式服务拆分业务逻辑完成解耦的架构模式架构风格。微服务肯定是分布式的一种是在分布式技术成熟之后然后把分布式当成解耦手段来架构系统-----因为拆分的服务很细致服务数量规模开始变多了服务的体量开始缩小了由以前几个大的服务转变为多个独立运行的、原子性质的服务。 如图 微服务最重要的特性是 1、可用性描述一个系统在一段时间内提供有用资源的能力从而减少停工时间而保持其服务的高度可用性。 2、伸缩性根据需求动态添加和删除系统中资源的能力是水平或垂直扩展的专门实现。 集群负载均衡可以解决系统的高可用和伸缩特性。 优点 1、可以使用不同语言或者相同语言的不同版本开发各个模块。 2、系统耦合性低各个模块分而治之独立部署独立发布独立维护。 3、可以更快的相应市场的需求更符合敏捷开发。 4、可以对不同模块使用集群策略哪里有问题治哪里。 缺点 1、开发难度更大系统结构更复杂。 2、运行效率低网络调用成本很大。 5、SOA 面向服务架构 Service-Oriented Architecture 面向服务架构是一个组件模型它将应用程序的不同功能单元称为服务进行拆分并通过这些服务之间定义良好的接口和协议联系起来。 如图 三、微服务架构的发展历程 我们要解决微服务的高可用和可伸缩的两个问题自然就会想到通过集群来实现这个思路没有错。如果我们实现了服务集群那另外两个问题就会出现这两个问题也导致了微服务架构的发展版本的差异。第一个服务的发现问题调用方如何发现服务有了新的服务我们如何知道有服务实例掉线我们如何晓得发现服务就很重要这个是基础问题第一个问题不解决第二个问题也没有办法实现第二个如何调用服务如何管理那么多的服务实例。有那么多的集群实例也就有那么多的服务实例我们该怎么去调用这些服务呢多个服务调用的关系如何呢 由于这些问题那我们就看看微服务架构的三个版本是如何解决的。 1、集中式代理----NginxV1.0 版本服务注册/服务发现----手动 1、服务发现手动修改配置文件重新启动。 2、负载均衡可以轮训、权重、哈希等等。 3、服务新增无法发现需要手动配置服务掉线可以自动检查。 4、客户端的实现很简单不需要额外的代码简单高效。 2、客户端嵌入----ConsulV2.0版本服务注册/服务发现—自动---服务治理 1、服务注册与发现动态增加自动完成。 2、健康检查可以查看损坏服务去掉服务自动完成。 3、负载均衡Consul 返回所有活动服务实例客户端自己实现负载均衡。 功能强大自动发现-自动下线客户端集成比较复杂负载均衡在客户端实现。 3、服务网格-Service MeshV3.0---技术不成熟华为唯品会lstio SideCar服务管理服务实例的注册和发现服务实例的治理和调用。Service Mesh’s Control Plan 管理所有的 SideCar。这个技术我就不多谈了网上的资料也很多目前这个技术还不是很成熟使用的范围也不是很广只有一些大的公司有过使用比如微软等。 四、微服务架构必备技术栈 微服务是一种软件设计、架构思想当然里面也包含了相关技术点要解决当前要务。学习微服务我们不能空口而谈一定要落实到具体的技术栈上。当今使用比较多两个技术体系一个是Java另外一个就是Net废话不多说我是使用微软相关技术栈的软件架构人员当然使用的“微服务”架构技术栈也都是微软的。今天我就把相关“微服务架构”所用到的技术栈罗列出来我也要说明一下微服务架构里面的很多技术是和开发语言无关的无论是 .Net 还是 Java 平台都可以使用。以后一步一步的针对每项技术在做深入研究。 1、微服务架构----服务通信 WebService、WCF、WebAPI甚至可以是 ASHX,ASPX这都是微软本身的技术体系没什么可说的。 1、主动触发 2、数据序列化传递 3、跨平台。 4、跨语言 5、Http 穿透防火墙。 2、微服务架构----进程通信 1、Net RemotingNet 平台督邮的不支持跨平台。 2、gRPC高性能、开源和通用 RPC框架面向服务端和移动端基于 HTTP/2 设计推荐使用。 3、微服务架构---API网关服务Ocelot API网关—— 它是系统的暴露在外部的一个访问入口。这个有点像代理访问的家伙就像一个公司的门卫承担着寻址、限制进入、安全检查、位置引导、等等功能。Ocelot是一个用.NET Core实现并且开源的API网关它功能强大包括了路由、请求聚合、服务发现、认证、鉴权、限流熔断、并内置了负载均衡器与Service Fabric、Butterfly Tracing集成。这些功能只都只需要简单的配置即可完成。 如图 官网https://ocelot.readthedocs.io/en/latest/index.html 4、微服务架构—认证授权 现在的应用开发层出不穷基于浏览器的网页应用基于微信的公众号、小程序基于IOS、Android的App基于Windows系统的桌面应用和UWP应用等等这么多种类的应用就给应用的开发带来的挑战我们除了分别实现各个应用外我们还要考虑各个应用之间的交互通用模块的提炼其中身份的认证和授权就是每个应用必不可少的的一部分。而现在的互联网对于信息安全要求又十分苛刻所以一套统一的身份认证和授权就至关重要。IdentityServer4就是这样一个框架IdentityServer4是为ASP.NET CORE量身定制的实现了OpenId Connect和OAuth2.0协议的认证授权中间件。 项目地址https://github.com/IdentityServer/IdentityServer4 5、微服务架构—瞬态故障处理 Polly它一款强大的类库Polly是一种.NET弹性和瞬态故障处理库允许我们以非常顺畅和线程安全的方式来执诸如行重试断路超时故障恢复等策略。Polly针对 .NET 4.0.NET 4.5和.NET Standard 1.1以及.NET Core实现该项目作者现已成为.NET基金会一员项目一直在不停迭代和更新你值得拥有。 项目地址https://github.com/App-vNext/Polly 6、微服务架构----分布式追踪 随着微服务架构的流行一些微服务架构下的问题也会越来越突出比如一个请求会涉及多个服务而服务本身可能也会依赖其他服务整个请求路径就构成了一个网状的调用链而在整个调用链中一旦某个节点发生异常整个调用链的稳定性就会受到影响所以会深深的感受到 “银弹” 这个词是不存在的每种架构都有其优缺点 。 面对以上情况 我们就需要一些可以帮助理解系统行为、用于分析性能问题的工具以便发生故障的时候能够快速定位和解决问题这时候 APM应用性能管理工具就该闪亮登场了。 项目地址https://github.com/SkyAPM/SkyAPM-dotnet 7、微服务架构----分布式日志 一般我们需要进行日志分析场景直接在日志文件中 grep、awk 就可以获得自己想要的信息。但在规模较大也就是日志量多而复杂的场景中此方法效率低下面临问题包括日志量太大如何归档、文本搜索太慢怎么办、如何多维度查询。需要集中化的日志管理所有服务器上的日志收集汇总。常见解决思路是建立集中式日志收集系统将所有节点上的日志统一收集管理访问。 大型系统通常都是一个分布式部署的架构不同的服务模块部署在不同的服务器上问题出现时大部分情况需要根据问题暴露的关键信息定位到具体的服务器和服务模块构建一套集中式日志系统可以提高定位问题的效率。 1、Exceptionless 是一个开源的实时的日志收集框架它可以应用在基于 ASP.NETASP.NET CoreWeb ApiWeb FormsWPFConsoleMVC 等技术栈的应用程序中并且提供了Rest接口可以应用在 JavascriptNode.js 中。它将日志收集变得简单易用并且不需要了解太多的相关技术细节及配置。在以前我们做日志收集大多使用 Log4netNlog 等框架在应用程序变得复杂并且集群的时候可能传统的方式已经不是很好的适用了因为收集各个日志并且分析他们将变得麻烦而且浪费时间。 现在Exceptionless团队给我们提供了一个更好的框架来做这件事情我认为这是非常伟大并且有意义的感谢他们。 官网http://exceptionless.com/ GitHubhttps://github.com/exceptionless/Exceptionless 2、ELK是三个开源软件的缩写分别为Elasticsearch 、 Logstash以及Kibana , 它们都是开源软件。不过现在还新增了一个Beats它是一个轻量级的日志收集处理工具(Agent)Beats占用资源少适合于在各个服务器上搜集日志后传输给Logstash官方也推荐此工具目前由于原本的ELK Stack成员中加入了 Beats 工具所以已改名为Elastic Stack。推荐使用。 8、微服务架构----分布式配置中心 Apollo阿波罗是携程框架部门研发的配置管理平台能够集中化管理应用不同环境、不同集群的配置配置修改后能够实时推送到应用端并且具备规范的权限、流程治理等特性。 服务端基于 Spring Boot 和 Spring Cloud 开发打包后可以直接运行不需要额外安装 Tomcat 等应用容器。 Java 客户端不依赖任何框架能够运行于所有 Java 运行时环境同时对 Spring 环境也有较好的支持。 .Net 客户端不依赖任何框架能够运行于所有 .Net 运行时环境。 项目地址https://github.com/ctripcorp/apollo/ 9、微服务架构----分布式锁 分布式锁的解决方案有很多我在这里就罗列一些我会在以后的实践中实现这些技术点。 1、Consul 可以实现分布式锁 2、Redis 可以实现分布式锁推荐使用。 3、Zookeeper 可以实现分布式锁 4、数据库 可以实现分布式锁 10、微服务架构----分布式事务 分布式事务的实现方式也不少以后努力学习吧。 1、2PCtwo-phase commit protocol强一致性没有可用性 2、3PC 3、TCCTry-Confirm-Cancel 4、本地消息表推荐 RabbitMQ。 5、Saga 模式 本地消息表MQ分布式事务—本地消息表—基于消息的一致性。 1、上有投递消息 2、下游获取消息 3、上游投递稳定性 4、下游接受稳定性 11、微服务架构—容器化 Docker 是一个开源的应用容器引擎可以打包应用以及依赖包到一个可移植的镜像中然后发布到任何流行的 Linux 和Windows 机器上也可以实现虚拟化。 Docker 使用客户端-服务器 (C/S) 架构模式使用远程API来管理和创建Docker容器。Docker 容器通过 Docker 镜像来创建。容器与镜像的关系类似于面向对象编程中的对象与类。 Docker采用 C/S架构 Docker daemon 作为服务端接受来自客户的请求并处理这些请求创建、运行、分发容器。客户端和服务端既可以运行在一个机器上也可通过 socket 或者RESTful API 来进行通信。 Docker daemon 一般在宿主主机后台运行等待接收来自客户端的消息。Docker 客户端则为用户提供一系列可执行命令用户用这些命令实现跟 Docker daemon 交互。 如图 12、微服务架构—容器编排 Kubernetes是Google开源的一个容器编排引擎它支持自动化部署、大规模可伸缩、应用容器化管理。在生产环境中部署一个应用程序时通常要部署该应用的多个实例以便对应用请求进行负载均衡。 在Kubernetes中我们可以创建多个容器每个容器里面运行一个应用实例然后通过内置的负载均衡策略实现对这一组应用实例的管理、发现、访问而这些细节都不需要运维人员去进行复杂的手工配置和处理。 Kubernetes 也可以理解为Docker 的编排容器是管理应用的全生命周期的工具从创建应用/部署应用提供服务扩容缩容更新都非常的方便而且可以做到故障自愈 中文社区http://docs.kubernetes.org.cn/ 官网https://kubernetes.io/docs/home/ 13、微服务架构—CI/CD Jenkins 是一个开源的、提供友好操作界面的持续集成CI工具主要用于持续、自动的构建/测试软件项目、监控外部任务的运行。 官网: http://www.jenkins.org.cn/五、 结束语 好了今天就写到这里了今天还是写了不少东西今天没别的就是做一下相关技术栈的记录以后有时间再把每项技术仔细研究可能是每项技术也可能是以一个项目来研究这个项目中可能包含很多其他的技术到时候再决定。每天进步一点加油。
