.Net 微服务架构技术栈的那些事

一、前言

大家一直都在谈论微服务架构，园子里面也有很多关于微服务的文章，前几天也有一些园子的朋友问我微服务架构的一些技术，我这里就整理了微服务架构的技术栈路线图，这里就分享出来和大家一起探讨学习，同时让新手对微服务相关技术有一个更深入的了解。

二、技术栈

2.1 工欲善其事，必先利其器

现在互联网盛行的年代，互联网产品也层出不穷，受欢迎的互联网产品都有一个比较牛的技术团队，我这里分享下.net 微服务架构技术栈图如下：

 

俗话说得好：工欲善其事，必先利其器。一个优秀的工程师应该善于使用框架和工具，在微服务这一块的技术选型并非一蹴而就，需要经过日积月累和落地的项目才能完善。
下文我会一一分享技术栈中的主要框架和工具的使用场景，这篇文章就不一一分享实战例子。

2.2 微服务

微服务如何“微”？

微服务，当然核心是主题是“微”，怎么微呢？应该如何微呢？在我刚来杭州的时候接触过一个电商系统的单体架构，系统比较庞大，结合了各种电商该拥有的业务逻辑和场景，
代码也比较难于维护，前前后后接手的人也比较多，代码耦合度太高，改个业务逻辑基本上是牵一发而动全身，跟我上个月分享的关于
Asp.Net Core 中IdentityServer4 授权中心之应用实战的文章中的电商系统最初的架构图类似，如下：

 

那针对这个架构就有可“微”之谈了。

这里针对该单体架构可以做如下几个原则上进行“微”服务:

• 根据业务来进行拆分，一个业务一个服务原则进行拆分，做到通用性业务服务模块，这样业务之间可以做到高内聚低耦合。后面随意改动哪一块业务，只需要去改动这一块的业务微服务即可，其他业务不会受到影响。
• 一个业务模块一个独立的数据库为原则，相互平行的业务做到不需要相互依赖调用。
• 外层API网关进行业务逻辑的整合。
• 一个业务数据库一个微服务为原则。
• 结合分布式服务，可以快速版本迭代，发布平滑发布，不受时间影响，没时每刻都可以发布，无需半夜等到12点进行发布。（比较痛苦的发布，犹如三日凌空般(有点夸张)，曾经有段时间是每周都有那么几个晚上痛苦的发布，一发布就可能是凌晨4，5点，很多时候发布完，还要经过各种测试，最后发现问题还得线上改bug，我们回去的时候别的同事已经来上班了；当时我们的技术大佬说过这么一句话：“他连续一周都没看到过他的儿子，回去的时候，他儿子早就睡着了，起来上班的时候，他儿子已经去学校了”，大家一定也有过这样的发布经历。）

按照上面的原则后，原来的电商单体架构微服务改造升级后架构图如下：

 

架构图粗略的画了下，能够表明意思即可，微服务、Docker、k8s那一块简要