net core 微服务架构技术栈
嘟哒妈妈2019-02-01 14:58
本人在多家企业工作，经历了不同架构方式的微服务开发，因此就自己对微服务的粗浅认识，编写本文，希望能帮助想改造自身已有架构转投微服务架构的企业，或从头构建自己的微服务架构平台的企业走向成功。
微服务的概念
微服务(Microservice)概念据说是在2012年出现，其一出现就对互联网行业产生了巨大影响，因为其理念刚好符合“分而治之”的思想，在日益巨大化的互联网行业内，不免逐步产生了无法把控的思绪混乱，而“微”刚好能解决这个痛点。
微服务的精髓
“分而治之”是微服务的精髓！理解了这个精髓，就可以如庖丁解牛般设计你的系统架构。每个相对独立的业务均可拆分为微服务，微服务高度自治，数据、缓存、接口都是自我管理的，不要麻烦别的服务区管理，微服务间的通信一般约定为接口间的通讯和异步消息的通讯。微服务和微服务组合共同提供外部的接口，已形成更大的服务。
微服务的复杂度
由于把许多独立的业务拆成不同的微服务，因此带来的微服务构建的复杂度，一般表现为下列几点：
微服务的注册和发现微服务的部署和弹性伸缩微服务间的通讯微服务间通讯的效率微服务间的事务性（ACID）微服务的对外网关、限流熔断微服务的全局配置微服务的认证授权（OAuth2）微服务间的异步通讯、消息微服务的日志微服务的监控以上难题也是大型分布式应用的难题。Java世界的微服务Spring Cloud
在Java世界里Spring Cloud 已经成为微服务开发的主流技术栈，其核心组件如下图所示。
这里不是一篇Java技术的介绍，因此，java方面的介绍略去，有兴趣的朋友可以自己度娘相关内容。这里需要对标Java提取其核心微服务组件，提炼.net core 下需要构建的微服务核心组件。
.net core 微服务架构选型
针对微服务的兴起，微软也给出了自家的方案，对比如下图：
微服务落地选型
如果你是基于微软云构建系统，那么恭喜你，你直接选择Service Fabric，可以为你节省半年到1年的架构开发工作！
如果你不是基于微软云构建的系统，那么，怎么说呢？？你需要自己构建属于你的一套微服务解决方案。
什么？为什么啊？
.net core 的生态决定着目前为止，并没有比较好的合适的框架能够迅速落地，结合没加企业的不同状况，自己研发一套更为合适。
.net core 自研落线一
最简单的方案，没有之一：选择原生的asp.net core api方式构建微服务。
对标下列内容：
微服务的注册和发现 ：集成诸如Zookeeper之类的服务微服务的部署和弹性伸缩: docker + Kubernetes微服务间的通讯：Http WebApi微服务间通讯的效率:低，有级联崩溃的可能性微服务间的事务性（ACID）:CAP或异步通讯+人工处理微服务的对外网关、限流熔断:nginx/Kubernetes/IIS/自己轻量包装微服务的全局配置:DB/Redis/zookeeper微服务的认证授权（OAuth2）:IdentityServer微服务间的异步通讯、消息:RabbitMq等类似组件微服务的日志: log4net /Rabbitmq微服务的监控：HealthCheck接口该方案实施起来快速稳定，能满足小公司到中型公司的过渡。
.net core 自研落线二
最简单的方案，没有之一：选择Thrift、Grpc、dotnetty等方式构建微服务。
对标下列内容：
微服务的注册和发现 ：集成诸如Zookeeper之类的服务微服务的部署和弹性伸缩: docker + Kubernetes微服务间的通讯：RPC微服务间通讯的效率:高微服务间的事务性（ACID）:CAP或异步通讯+人工处理微服务的对外网关、限流熔断:nginx/Kubernetes/IIS/自己轻量包装微服务的全局配置:Apollo等类似相关配置中心微服务的认证授权（OAuth2）:IdentityServer微服务间的异步通讯、消息:RabbitMq等类似组件微服务的日志: 三方组件/自研微服务的监控：CAT、 KariosDB三方集成该方案实施起来快速稳定，能满足中小公司到大型公司的过渡。
微服务的总结
微服务相关的一系列配套组件，不一定都要非常好的解决掉才能上线，企业内部可以按照自己的规模和实际技术积累情况进行裁剪，很多运维和监控方面的组件也许会在后期才去重视，这也是现实逼迫所致，无可厚非。
但有一点需要提早规划，那就是怎么支持分布式事务，架构拆分成微服务后，和之前的架构区别最大的就是次点，因此需要提前规划重视！
举报/反馈
0
0
收藏
分享
