本人在多家企业工作，经历了不同架构方式的微服务开发，因此就自己对微服务的粗浅认识，编写本文，希望能帮助想改造自身已有架构转投微服务架构的企业，或从头构建自己的微服务架构平台的企业走向成功。
微服务的概念
微服务(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三方集成
该方案实施起来快速稳定，能满足中小公司到大型公司的过渡。
微服务的总结
微服务相关的一系列配套组件，不一定都要非常好的解决掉才能上线，企业内部可以按照自己的规模和实际技术积累情况进行裁剪，很多运维和监控方面的组件也许会在后期才去重视，这也是现实逼迫所致，无可厚非。
但有一点需要提早规划，那就是怎么支持分布式事务，架构拆分成微服务后，和之前的架构区别最大的就是次点，因此需要提前规划重视！
