AgileConfig 1.6.0 发布 - 支持服务注册与发现
大家好，好久没有输出博文了，一是因为比较忙，另外一个原因是最近主要的精力是在给 AgileConfig 添加一个新的功能：服务注册与发现。先说说为什么会添加这个功能。我自己的项目是用 Consul 来做为服务注册发现组件的。自从我上线了 AgileConfig 做为配置中心后，我就很少去 Consul 观察服务的在线状态了，因为 AgileConfig 客户端列表已经在一定程度上能代表服务的状态了。服务注册发现与配置中心其实本质上都是解决了一类问题，那就是配置的动态化，所以大家会看到业界著名的组件很多都是同时实现这2个功能的，如 Consul，Nacos 等。所以我想干脆把这个功能给加上吧...
.NET 微服务——CI/CD（3）：镜像自动分发
如何通过Jenkins完成镜像分发？基本做法是：打包镜像→上传镜像到仓库→脚本分发。镜像仓库也有很多，比如docker hub、Harbor等，今天这一篇讲一下基于阿里云镜像仓库的操作。首先，准备一个阿里云镜像仓库，个人版是免费的。然后下载这个插件：Publish Over SSH这个插件主要用来远程登录服务器并执行脚本。插件安装完毕后，系统设置会多出这一项，戳图里这个按钮：然后，把服务器的ip、账户、密码填进去：配置好以后，最好点测试按钮试一下，如果没问题会输出“Success”接下来找到之前的工作流，新增构建步骤：选中刚才新增的server，编写脚本进行上传...
Why I don’t like layered architecture for microservices
Many organisations are migrating to making use of the Microservice philosophies in developing systems. Generally this makes complete sense and can potentially provide dramatic performance benefits. However, unfortunately many organisations make the same mistakes when it comes to implementing their microservices.
Prioritizing and Microservices
It's not unusual to have different levels of prioritization in backend systems. Imagine you have a process that generates and sends reports that users have requested. Some of these might be low-priority reports that are simply generated periodically so they're available to view, while others might be generated on demand, with a user actively waiting for the results. These could be further differentiated based on the user's role or whether they're a free user or a paying subscriber, etc.
Organizing (Commands, Events & Handlers) in Microservices
In a message-driven architecture such as SOA or Microservices, organizing commands and events, along with their respected handlers, can have a big impact on have you navigate your codebase. You might be surprised by the progression of how I organized them initially to what I do now! Also a tip on how to name commands and Events instead of after CRUD.
.Net微服务实战之必须得面对的分布式问题
不少小伙伴看了我的博客的后跟我探讨问题时都离不开数据一致性、数据关联、数据重复创建的问题，只要大家做的分布式系统无论是否微服务化，或多或少都会遇到上述问题，而上述的问题的本质其实就是分布式事务、分布式数据关联与幂等性。这三个问题也是很多面试官在面试的时候检验应聘者是否有实践过分布式系统的经验的标准之一，而微服务作为分布式系统的架构风格，在实施过程中也无法幸免以上问题。
Building microservices through Event Driven Architecture part12 : Produce events to Apache KAFKA
This tutorial is the 12th part of a series : Building microservices through Event Driven Architecture. The previous step is about building microservices through Event Driven Architecture part11: Continuous Integration. In this tutorial, I will show how to publish events to apache KAFKA.
.NET Core 使用 Consul 服务注册发现
Consul是一个用来实现分布式系统服务发现与配置的开源工具。它内置了服务注册与发现框架、分布一致性协议实现、健康检查、Key/Value存储、多数据中心方案，不再需要依赖其他工具，使用起来也较为简单。
.Net微服务实战之Kubernetes的搭建与使用
说到微服务就得扯到自动化运维，然后别人就不得不问你用没用上K8S。无论是概念上还是在实施搭建时，K8S的门槛比Docker Compose、Docker Swarm高了不少。我自己也经过了多次的实践，整理出一套顺利部署的流程。我这次搭建花了一共整整4个工作实践与一个工作日写博客，中间有一个网络问题导致reset了集群重新搭了一次，完成后结合了Jenkins使用，还是成就感满满的。如果对大家有用，还请点个推荐与关注。
.Net微服务实战之负载均衡（上）
分布式？集群？负载均衡？我曾经面试过一家企业，当时描述完我在老东家完成的微服务架构后，面试官问了我一个问题：面试官：您有做过分布式系统吗？我：有，刚刚我描述的微服务架构就是分布式的……面试官：不不不，我意思是你有没有尝试过把一个站点部署到多台服务器上？我：哦……你意思是我有没有用过类似nginx这些工具做负载均衡是吧？有，现在我们就这么做的。但是我对分布式理解是工作方式，但是你描述的更...
.Net微服务实战之DevOps篇
该系列的两篇文章《.Net微服务实战之技术选型篇》和《.Net微服务实战之技术架构分层篇》都是以技术角度出发描述微服务架构的实施。如果技术选型篇叙述的是工具，那么架构分层篇讲的就是技巧，而本篇要讨论的就是原则。一直以来我会给身边向我探讨问题的人灌输一种理念，没有什么技术银弹，因为我们做的是软件工程，提供的是问题相应的解决方案，不同类型问题的解决方案是存在着本质上的差异。继续提供之前的源码：https://github.com/SkyChenSky/Sikiro
.Net微服务实战之技术架构分层篇
上一篇《.Net微服务实战之技术选型篇》，从技术选型角度讲解了微服务实施的中间件的选择与协作，工欲善其事，必先利其器，中间件的选择是作为微服务的基础与开始，也希望给一直想在.Net入门微服务的同行有一个很好的方向。在此篇重新整理了一下整个微服务项目的demo，希望对有需要的朋友起到一定的帮助：https://github.com/SkyChenSky/Sikiro
.Net微服务实践（五）[服务发现]：Consul介绍和环境搭建
在上篇.Net微服务实践（四）[网关]：Ocelot限流熔断、缓存以及负载均衡中介绍Ocelot的限流、熔断、缓存、负载均衡以及其他一些特性，Ocelot的基本配置和功能都已经介绍完了。本篇我们会介绍服务发现Consul.
.Net 微服务架构技术栈的那些事
大家一直都在谈论微服务架构，园子里面也有很多关于微服务的文章，前几天也有一些园子的朋友问我微服务架构的一些技术，我这里就整理了微服务架构的技术栈路线图，这里就分享出来和大家一起探讨学习，同时让新手对微服务相关技术有一个更深入的了解。
微服务容错 - 隔离熔断限流
在高并发访问下，系统所依赖的服务的稳定性对系统的影响非常大，依赖有很多不可控的因素，比如网络连接变慢，资源突然繁忙，暂时不可用，服务脱机等。我们要构建稳定、可靠的分布式系统，就必须要有这样一套容错机制。常用的的容错技术如：隔离，降级，熔断，限流等策略，本文将详细的介绍微服务中的容错机制。
surging 微服务引擎 2.0 会有多少惊喜？
surging微服务引擎从2017年6月至今已经有两年的时间，这两年时间有多家公司使用surging 服务引擎，并且有公司搭建了CI/CD，并且使用了k8s 集群，这里我可以说下几家公司的服务搭建情况，公司名不便透露，我们就以字母标识A公司:40多个服务提供者，一个服务提供者扩展了四五个实例节点，只使用了3台服务器，并且搭建了CI/CD, k8s 集群，使用suring 构建航空行业信息化系统B公司：房产系统，门店2300多家，峰值在线使用人数1700，平均保持在1200人左右，有21个服务提供者，每个服务提供者有70-80个服务，使用了三台服务器，部署在linux环境，并且使用docker,...
Consul初探-集成ocelot
由于 Consul 的高可用性、丰富的API、友好的 Web 控制台界面等特点，Consul 的发展非常迅猛，得益于 .NETCore 社区的快速发展和社区成员的贡献，我们现在可以非常方便快速的将 Consul 集成到 .NETCore 中，在 Ocelot 的集成方面也是非常的便捷，在 API Gateway 项目中，只需要通过引用一个包，就可以在项目中服务发现了。
构建自己的简单微服务架构（开源）
环境准备 .Net Core 集成 CAP Cap 发布 Cap 订阅（接收） 最后——附上总体代码 总体介绍随着业务需求的快速发展变化，需求不断增长，迫切需要一种更加快速高效的软件交付方式。微服务可以弥补单体应用不足，是一种更加快速高效软件架构风格。单体应用被分解成多个更小的服务，每个服务有自己的独立模块，单独部署，然后共同组成一个应用程序。把范围限定到单个独立业务模...
基于.net core微服务（Consul、Ocelot、Docker、App.Metrics+InfluxDB+Grafana、Exceptionless、数据一致性、Jenkins）
基于.net core微服务（Consul、Ocelot、Docker、App.Metrics+InfluxDB+Grafana、Exceptionless、数据一致性、Jenkins）1、微服务简介一种架构模式，提倡将单一应用程序划分成一组小的服务，服务之间互相协调、互相配合，为用户提供最终价值。每个服务运行在其独立的进程中，服务与服务间采用轻量级的通信机制互相沟通（RESTful API）。每...
我的微服务观，surging 2.0将会带来多大的改变
我的微服务观，surging 2.0将会带来多大的改变Surging 自2017年6月16日开源以来，已收到不少公司的关注或者使用，其中既有以海克斯康超大型等外企的关注，也不乏深圳泓达康、重庆金翅膀等传统行业的正式使用，自2019年年初，surging2.0 便已正式进入研发阶段，也受到了surging 用户的关注，本文将为您解读2.0的新特性和新功能。在开始之前先解答一下经常被提到的疑问1....