Grpc介绍 GitHub: https://github.com/grpc/grpc gRPC是一个高性能.通用的开源RPC框架,其由Google主要面向移动应用开发并基于HTTP/2协议标准而设计,基于ProtoBuf(Protocol Buffers)序列化协议开发,且支持众多开发语言.gRPC提供了一种简单的方法来精确地定义服务和为iOS.Android和后台支持服务自动生成可靠性很强的客户端功能库.客户端充分利用高级流和链接功能,从而有助于节省带宽.降低的TCP链接次数.节省CPU使用

快速入门 安装 JDK 毫无疑问,要想玩Java,就必须得先装Java JDK,目前公司主要使用的是Oracle JDK 8,安装完成后要配置环境才能正常使用,真蠢,不过也就那么一下下,认了吧.配置方法参考: http://www.runoob.com/java/java-environment-setup.html IDE 个人认为Java最好用的IDE就是IntelliJ IDEA (后面会简称IDEA).IDEA最大的优势就是可定制能力很高.同时有着各种各样的插件能提供不少的扩展和便利.但

1.下载安装traefik https://github.com/containous/traefik/releases 2.下载安装etcd3 https://github.com/coreos/etcd/releases 3.配置traefik,监控etcd的k-v,traefik使用文档地址 https://docs.traefik.io/master/user-guide/grpc/ [etcd] prefix = "/myservice" watch=true endpoin

安装protobuf 在windows下,直接下载release版本https://github.com/protocolbuffers/protobuf/releases/tag/v3.9.0然后把bin目录加入到环境变量中如果是在Linux下,下载对应的版本,然后编译,把编译后的文件加入env中 安装go protobuf plugin 可以参考这里: https://studygolang.com/articles/11343 go get -u github.com/golang/pro

gRPC 是什么 gRPC是goole开源的一个RPC框架和库,支持多语言之间的通信.底层通信采用的是 HTTP2 协议.gRPC在设计上使用了 ProtoBuf 这种接口描述语言.这种IDL语言可以定义各种服务,google还提供了一种工具 protoc 来编译这种IDL语言,生成各种各样的语言来操作服务. gPRC特点 定义服务简单,可以很快的搭建出一个RPC调度的服务 gRPC是与语言无关,平台无关的.你定义好了一个protobuf协议,就可以用protoc生成不同语言的协议框架 使用HT

1.使用SqlSuger组件时同一API无法自动切库 1.1 在生成Model时在类上加上特性 1.2 一个接口如果使用了多个数据库实例,会出现库找不到,需要使用ChangeDataBase切库 2.接口批量删除或修改 https://www.iaspnetcore.com/Blog/BlogPost/59e777dedc77c218ac262788/see-the-webapi-interface-get-request-parameter-pass-through-several-examp

https://realpython.com/python-microservices-grpc/ https://www.manning.com/books/developing-microservice-apis-with-python https://www.freecodecamp.org/news/python-microservices-course/ https://cloudacademy.com/course/mastering-microservices-with-pytho

上一次我们通过一张架构图(.Net Core with 微服务 - 架构图)来讲述了微服务的结构,分层等内容.从现在开始我们开始慢慢搭建一个最简单的微服务架构.这次我们先用几个简单的 web api 项目以及 ocelot 网关项目来演示下网关是如何配置,如何工作的. Ocelot 网关 Ocelot 是使用 asp.net core 开发的一个 api 网关项目.它功能丰富,集成了路由.限流.缓存.聚合等功能.它使用 .net 编写,本质上就是一堆 asp.net core 的中间件,所以它天

上一次我们介绍了 Ocelot 网关的基本用法.这次我们开始介绍服务注册发现组件 Consul 的简单使用方法. 服务注册发现 首先先让我们回顾下服务注册发现的概念. 在实施微服务之后,我们的调用都变成了服务间的调用.服务间调用需要知道IP.端口等信息.再没有微服务之前,我们的调用信息一般都是写死在调用方的配置文件里(当然这话不绝对,有些公司会把这些信息写到数据库等公共的地方,以方便维护).又由于业务的复杂,每个服务可能依赖N个其他服务,如果某个服务的IP,端口等信息发生变更,那么所有依赖该服务

上一次我们介绍并演示了如果使用 Consul 做为我们微服务的注册中心,来实现服务的注册与发现.那么本次我们讲会演示如何做日志聚合.日志聚合比较常用的有 ELK 等,但是这次我想要介绍的是一款比较小众的日志聚合工具 - Seq . 日志聚合 日志是我们写程序离不开的一个东西.在我们排查问题的时候日志就是我们的救命稻草.我们的每个服务都在不停的生产日志.但是实施微服务后,如果按照传统的写本地文件的日志方案,显然会面临跟修改配置一样麻烦的境地.不同的日志分散在各个服务器.容器内,这种情况下查日志简直

上一次我们介绍了Seq日志聚合组件.这次要给大家介绍的是Elastic APM ,一款应用程序性能监控组件.APM 监控围绕对应用.服务.容器的健康监控,对接口的调用链.性能进行监控.在我们实施微服务后,由于复杂的业务逻辑,服务之间的调用会像蜘蛛网一样复杂.有了调用链监控后服务之间的调用可以用图像的方式展示出来,每个请求的性能,响应等都会记录下来.对于提前防范问题,以及排查问题有非常大的意义. Elastic APM 大家对 ELK 套件一定非常熟悉.ELastic APM 同样也是 Elast

上一次我们介绍了Elastic APM组件.这一次我们继续介绍微服务相关组件配置中心的使用方法.本来打算介绍下携程开源的重型配置中心框架 apollo 但是体系实在是太过于庞大,还是让我爱不起来.因为前面我们已经介绍了使用Consul 做为服务注册发现的组件,那么干脆继续使用 Consul 来作为配置中心吧.Consul 除了服务注册发现功能,还有个 Key/Value 存储的功能,我们把本地的 appsettings.json 文件的内容搬到 Key/Value 上就可以实现配置中心了. 把服

在我们实施微服务之后,服务间的调用变的异常频繁.多个服务之间可能是互相依赖的关系.某个服务出现故障或者是服务间的网络出现故障都会造成服务调用的失败,进而影响到某个业务服务处理失败.某一个服务调用失败轻则造成当前相关业务无法处理:重则可能耗尽资源而拉垮整个应用.为了尽可能的保证我们生产环境的可用性,至少是部分可用性我们就需要一些策略来保护我们的服务. 服务降级 比如我们的订单详情服务里面会调用会员信息服务接口.如果会员信息服务接口故障会造成订单详情服务也同样故障.这时候我们可以对会员信息服务接口进

最近比较忙,好久没更新了.这次我们来聊一聊分布式事务. 在微服务体系下,我们的应用被分割成多个服务,每个服务都配置一个数据库.如果我们的服务划分的不够完美,那么为了完成业务会出现非常多的跨库事务.即使按照 DDD 的原则来切分服务还是免不了有的业务场景需要多个业务同时提交成功或者同时回滚的场景.比如会员使用积分下订单这个场景,那么会员服务的积分扣减需要跟订单下单成功同时完成.如果下单成功,但是扣减积分接口失败,那么就会造成数据的不一致性.这个时候我们就需要使用分布式事务来保证数据的一致性. 由于

上一次我们讲解了分布式事务的 2PC.3PC .那么这次我们来理一下 TCC 事务.本次还是讲解 TCC 的原理跟 .NET 其实没有关系. TCC Try 准备阶段,尝试执行业务 Confirm 完成业务 Cancel 回滚准备阶段的业务 TCC 事务其实是 2PC 的一个扩展.上一次我们说了 2PC ,在二阶段进行事务提交.因为 2PC 基本上是利用数据库的 事务能力进行 commit ,其实这里还有可能出现一种 rollback 情况. TCC 就是把 2PC 的二阶段细化了,拆分成了 C

前面我们讲了分布式事务的2PC.3PC , TCC 的原理.这些事务其实都在尽力的模拟数据库的事务,我们可以简单的认为他们是一个同步行的事务.特别是 2PC,3PC 他们完全利用数据库的事务能力,在一阶段开始事务后不进提交会严重影响应用程序的并发性能.TCC 一阶段虽然不会阻塞数据库,但是它同样是在尽力追求同时成功同时失败的一致性要求.但是在很多时候,我们的应用程序的核心业务为了追求更高的性能.更高的可用性,可以允许在一段时间内的数据不一致性,只需要在最终时刻数据是一致就可以了.基于以上场景我们

Service Resilience是指当服务的的运行环境出现了问题,例如网络故障或服务过载或某些微服务宕机的情况下,程序仍能够提供部分或大部分服务,这时我们就说服务的韧性很强.它是微服务中很重要的一部分内容,并被广泛讨论.它是衡量服务质量的一个重要指标.Service Resilience从内容上讲翻译成"容错"可能更接近, 但"容错"英文是"Fault Tolerance",它的含义与"Service Resilience"

我使用Go和gRPC创建了一个微服务,并试图找出最佳的程序结构,它可以用作我未来程序的模板. 我有Java背景,并发现自己在Java和Go之间挣扎,它们之间的编程理念完全不同.我写了一系列关于在项目工作中做出的设计决策和取舍的文章. 这是其中的第一篇, 是关于程序结构的. 程序结构的资源 Go的标准程序结构的最佳资源可能是Github上的标准Go程序结构¹,但它不适合我的项目.在阅读了Sylvain Wallez的文章²之后,我终于得到了一些关于其背后原因的信息. Go起初是专为API和网络服务

随笔分类 - 微服务 .net core使用NLog+Elasticsearch记录日志 摘要:在微服务或分布式系统中,如果将日志作为文件输出,查看系统日志将非常不便:如果将日志保存到数据库中,又不能进行全文搜索.在这里我们将日志输出到ElasticSearch中,借助Kibana再查找日志. 添加Nuget引用 需要添加两个Nuget引用:NLog.Web.AspNetCore和NLog.T 阅读全文 posted @ 2018-06-08 11:51 focus-lei 阅读 (861) |

清晰架构(Clean Architecture)的一个理念是隔离程序的框架,使框架不会接管你的应用程序,而是由你决定何时何地使用它们.在本程序中,我特意不在开始时使用任何框架,因此我可以更好地控制程序结构.只有在整个程序结构布局完成之后,我才会考虑用某些库替换本程序的某些组件.这样,引入的框架或第三方库的影响就会被正确的依赖关系所隔离.目前,除了logger,数据库,gRPC和Protobuf(这是无法避免的)之外,我只使用了两个第三方库ozzo-validation¹和YAML²,而其他所有库

为了支持业务层中的事务,我试图在Go中查找类似Spring的声明式事务管理,但是没找到,所以我决定自己写一个. 事务很容易在Go中实现,但很难做到正确地实现. 需求: 将业务逻辑与事务代码分开. 在编写业务用例时,开发者应该只需考虑业务逻辑,不需要同时考虑怎样给业务逻辑加事务管理.如果以后需要添加事务支持,你可以在现有业务逻辑的基础上进行简单封装,而无需更改任何其他代码.事务实现细节应该对业务逻辑透明. 事务逻辑应该作用于用例层(业务逻辑) 不在持久层上. 数据服务(数据持久性)层应对事务逻辑透