一.简介 本篇我们将会把商城的服务部署到k8s中,同时变化的还有以下两个地方: 1.不再使用Consul做服务的注册和发现,转而使用k8s-dns来实现. 2.不再使用Ocelot作为业务网关,使用Traefik来实现. 正如上面所讲,服务发现和网关均使用k8s的相关工具,当然,相比与以上两个工具,Traefik还有自己的不足,比如Consul的健康检查.Ocelot的限流.熔断机制,不过这些我们后面可以通过其它方式来实现. 整体思路很简单哈,就是编写Dockerfile文件,将各个服务打包成镜

前言 最近一直在开发部署.也没有总结一下.从5月份开始出差到现在基本没有发过博客,哎,惭愧. 一直在弄微服务,后续会慢慢更新下面这个系列.欢迎各位大佬交流指点. 分布式理论专题 1..net core 2.2 环境准备 系统:SUSE 12 SP3 NET Core runtime: 2.2.1 这里可以参考我之前写的这篇博客 SUSE12Sp3-.NET Core 2.2.1 runtime安装 2.使用vs2019发布.netcoreapp2.2程序 然后上传至LINUX 服务器 3.安装配

Tip: 此篇已加入.NET Core微服务基础系列文章索引 一.CI, CD 与Jenkins 互联网软件的开发和发布,已经形成了一套标准流程,最重要的组成部分就是持续集成(Continuous integration,简称 CI) => 持续集成指的是,频繁地(一天多次)将代码集成到主干. 它的好处主要有两个: 快速发现错误.每完成一点更新,就集成到主干,可以快速发现错误,定位错误也比较容易. 防止分支大幅偏离主干.如果不是经常集成,主干又在不断更新,会导致以后集成的难度变大,甚至难以集成.

简介 系列目录:[NET CORE微服务一条龙应用]开始篇与目录 本章主要介绍https://github.com/q315523275/FamilyBucket上微服务一条龙应用,在实际使用中的应用部署,以原始方式部署非docker 部署应用主要包括: 1.网关应用部署 2.授权认证应用部署 3.配置中心查询服务端应用部署 4.综合管理应用部署 5.后台运行应用部署 6.数据初始化 运行环境 应用所需运行环境,相关技术点不做介绍 1.net core 2.2/2.1 2.mysql 3.rab

<ASP.NET Core 微服务实战>译者序:https://blog.jijiechen.com/post/aspnetcore-microservices-preface-by-translator/ "微服务"的概念在 2014 年正式提出之后,越来越多的团队开始用它来设计自己的业务系统,各种微服务框架和开发过程管理方法也同时兴起.不断成熟.微服务设计方法清晰地定义了各个开发团队的业务边界,微服务框架以不同的方式实现了服务之间的协作与集成,根据康威定律我们可以推导这

一.为啥要总结和收集这个系列? 今年从原来的Team里面被抽出来加入了新的Team,开始做Java微服务的开发工作,接触了Spring Boot, Spring Cloud等技术栈,对微服务这种架构有了一个感性的认识.虽然只做了两个月的开发工作,但是对微服务架构的兴趣却没有结束,又因为自己的.NET背景(虽然对.NET的生态有点恨铁不成钢),想要探索一下在.NET平台下的微服务架构的可行性,也准备一些材料作为分享的素材. 幸运的是,在.NET Core首届在线峰会上,看到了很多前辈的分享,也增强

Tip: 此篇已加入.NET Core微服务基础系列文章索引 一.Exceptionless极简介绍 Exceptionless 是一个开源的实时的日志收集框架,它可以应用在基于 ASP.NET,ASP.NET Core,Web API,Web Forms,WPF,Console,ASP.NET MVC 等技术开发的应用程序中,并且提供了REST接口可以应用在 Javascript,Node.js 中.它将日志收集变得简单易用并且不需要了解太多的相关技术细节及配置,对于微服务架构的应用程序来说,

Tip: 此篇已加入.NET Core微服务基础系列文章索引 一.Docker极简介绍 1.1 总体介绍 Docker 是一个开源的应用容器引擎,基于 Go 语言 并遵从Apache2.0协议开源.Docker 可以让开发者打包他们的应用以及依赖包到一个轻量级.可移植的容器中,然后发布到任何流行的 Linux 机器上,也可以实现虚拟化.容器是完全使用沙箱机制,相互之间不会有任何接口(类似 iPhone 的 app),更重要的是容器性能开销极低. 简而言之> 容器是一个打包了应用服务的环境,它是一

今年从原来的Team里面被抽出来加入了新的Team,开始做Java微服务的开发工作,接触了Spring Boot, Spring Cloud等技术栈,对微服务这种架构有了一个感性的认识.虽然只做了两个月的开发工作,但是对微服务架构的兴趣却没有结束,又因为自己的.NET背景(虽然对.NET的生态有点恨铁不成钢),想要探索一下在.NET平台下的微服务架构的可行性,也准备一些材料作为分享的素材. 幸运的是,在.NET Core首届在线峰会上,看到了很多前辈的分享,也增强了自己要摸索和实践.NET Co

一.为啥要写这个系列? 今年从原来的Team里面被抽出来加入了新的Team,开始做Java微服务的开发工作,接触了Spring Boot, Spring Cloud等技术栈,对微服务这种架构有了一个感性的认识.虽然只做了两个月的开发工作,但是对微服务架构的兴趣却没有结束,又因为自己的.NET背景(虽然对.NET的生态有点恨铁不成钢),想要探索一下在.NET平台下的微服务架构的可行性,也准备一些材料作为公司内部培训和分享课程的素材.幸运的是,在.NET Core首届在线峰会上,看到了很多前辈的分享

一.为啥要总结和收集这个系列? 今年从原来的Team里面被抽出来加入了新的Team,开始做Java微服务的开发工作,接触了Spring Boot, Spring Cloud等技术栈,对微服务这种架构有了一个感性的认识.虽然只做了两个月的开发工作,但是对微服务架构的兴趣却没有结束,又因为自己的.NET背景(虽然对.NET的生态有点恨铁不成钢),想要探索一下在.NET平台下的微服务架构的可行性,也准备一些材料作为分享的素材. 幸运的是,在.NET Core首届在线峰会上,看到了很多前辈的分享,也增强

是不是现在每个团队都需要上K8s才够潮流,不用K8s是不是就落伍了.今天,我就通过这篇文章来回答一下. 一.先给出我的看法和建议 我想说的是,对于很多的微小团队来说,可能都不是一定要上K8s,毕竟上K8s也是需要成本和人力的.对像我司一样的传统企业做数字化转型的信息团队来讲,人数不多,没有专门的Ops人员,领导又想要尽快迭代支持公司业务发展,而且关键还要节省成本(内心想法是:WTF). 在此之下,信息团队需要综合引入先进技术带来的价值以及需要承担的成本和风险.任何架构的产生,都会解决一定的问题,

Tips:本篇已加入系列文章阅读目录,可点击查看更多相关文章. 前言 上一篇[.Net Core微服务入门全纪录(八)--Docker Compose与容器网络]完成了docker-compose.yml文件的编写,最后使用docker compose的一个up指令即可在docker中运行整个复杂的环境.本篇简单介绍一下Ocelot与Swagger的集成,方便在网关项目中统一查看各个服务的api文档. 开始 首先,网关项目,服务项目 NuGet安装Swashbuckle.AspNetCore:

参考网址: https://archy.blog.csdn.net/article/details/103659692 2018年,我开始学习和实践.NET Core,并开始了微服务的学习,以及通过各种开源组件搭建服务治理技术方案,并在学习过程中总结了一个.NET Core微服务学习与实践系列文章,涵盖了服务发现.API网关.配置中心.验证授权.分布式日志.性能监控.事件总线等开源项目的使用,还介绍了基于Steeltoe这个开源项目让.NET Core可以在Spring Cloud框架下共享Sp

在基于 Kubernetes 的基础设施即代码一文中,我概要地介绍了基于 Kubernetes 的 .NET Core 微服务和 CI/CD 动手实践工作坊使用的基础设施是如何使用代码描述的,以及它的自动化执行过程.如果要查看基于 Kubernetes 的基础设施即代码架构全图,以及实现代码,请回到文章基于 Kubernetes 的基础设施即代码.本文,我们深入探讨其中 微服务部署部分的"基础设施即代码"的实现原理.一般来说,在一个团队,CI/CD 软件不会经常部署.与此不同,时常处于

Tip: 此篇已加入.NET Core微服务基础系列文章索引 一.Consul基础介绍 Consul是HashiCorp公司推出的开源工具,用于实现分布式系统的服务发现与配置.与其他分布式服务注册与发现的方案,比如 Airbnb的SmartStack等相比,Consul的方案更“一站式”,内置了服务注册与发现框 架.分布一致性协议实现.健康检查.Key/Value存储.多数据中心方案,不再需要依赖其他工具(比如ZooKeeper等),使用起来也较 为简单. Consul用Golang实现,因此具

Tip: 此篇已加入.NET Core微服务基础系列文章索引 一.REST or RPC ? 1.1 REST & RPC 微服务之间的接口调用通常包含两个部分,序列化和通信协议.常见的序列化协议包括json.xml.hession.protobuf.thrift.text.bytes等:通信比较流行的是http.soap.websockect,RPC通常基于TCP实现,常用框架例如dubbo,netty.mina.thrift. REST:严格意义上说接口很规范,操作对象即为资源,对资源的四种

Tip: 此篇已加入.NET Core微服务基础系列文章索引 一.啥是API网关? API 网关一般放到微服务的最前端,并且要让API 网关变成由应用所发起的每个请求的入口.这样就可以明显的简化客户端实现和微服务应用程序之间的沟通方式.以前的话,客户端不得不去请求微服务A(假设为Customers),然后再到微服务B(假设为Orders),然后是微服务C(假设为Invoices).客户端需要去知道怎么去一起来消费这三个不同的service.使用API网关,我们可以抽象所有这些复杂性,并创建客户端

Tip: 此篇已加入.NET Core微服务基础系列文章索引 一.负载均衡与请求缓存 1.1 负载均衡 为了验证负载均衡,这里我们配置了两个Consul Client节点,其中ClientService分别部署于这两个节点内(192.168.80.70与192.168.80.71). 为了更好的展示API Repsonse来自哪个节点,我们更改一下返回值: [Route("api/[controller]")] public class ValuesController : Contr

Tip: 此篇已加入.NET Core微服务基础系列文章索引 一.什么是Tracing? 微服务的特点决定了功能模块的部署是分布式的,以往在单应用环境下,所有的业务都在同一个服务器上,如果服务器出现错误和异常,我们只要盯住一个点,就可以快速定位和处理问题,但是在微服务的架构下,大部分功能模块都是单独部署运行的,彼此通过总线交互,都是无状态的服务,这种架构下,前后台的业务流会经过很多个微服务的处理和传递,我们会面临以下问题: 分散在各个服务器上的日志怎么处理? 如果业务流出现了错误和异常,如何定位

Tip: 此篇已加入.NET Core微服务基础系列文章索引 一.关于统一配置中心与Apollo 在微服务架构环境中,项目中配置文件比较繁杂,而且不同环境的不同配置修改相对频繁,每次发布都需要对应修改配置,如果配置出现错误,需要重新打包发布,时间成本较高,因此需要做统一的配置中心,能做到自动更新配置文件信息,解决以上问题. Apollo(阿波罗)是携程框架部门研发的配置管理平台,能够集中化管理应用不同环境.不同集群的配置,配置修改后能够实时推送到应用端,并且具备规范的权限.流程治理等特性.其服务