王者荣耀　

　　

去年我有幸被老领导邀请以系统架构师与技术负责人的角色带技术团队，并对公司项目以微服务进行了实施。无论是技术团队还是技术架构都是由我亲自的从0到1的选型与招聘成型的，此过程让我受益良多，因此也希望在接下来的系列博文尽可能的与大家分享我的经验。

　　

古人有云：将军难打无兵之仗。想要把微服务很好的实施也并非能一个人可以完成的事，一来需要有出色的运维提供支持，二来需要花时间做技术选型与攻关，三来还要开发兄弟们配合实施。因此，这次能顺利实施并不是一个人的王者，而是团队的荣耀。

　　

框架源码：https://github.com/SkyChenSky/Sikiro （文末有说明）

工欲善其事，必先利其器

　　

以上是我们公司的技术栈（点击图片可在浏览器打开），除了统一配置中心没有服务器资源和Hangfire还没场景使用外，其他都已经上线使用了。　　

　　

俗话说得好：工欲善其事，必先利其器。一个优秀的工程师应该善于使用框架和工具，在微服务这一块的技术栈选型并非一蹴而就，也是我多次对比验证后，并良好的集成到公司项目然后落地实施。这系列框架单纯这么去用其实是可以无缝集成的，但是在落实项目的时候，我为了集成得更加友好和使用上更加便利，在基础上做了扩展，例如SkyWalking添加Request和Response，CAP与Chloe.ORM的集成等，下文我会逐个分享。

　　

有需要的朋友可以参照我这套去实施，这样大家就可以花更多的时间把精力放在业务、调优、拆分、设计等方面。

　　

此外大家看得出，我所有的技术栈基本上找的都是开源社区的比较出名的项目，没有一个属于自研的。这样做的原因：

• 　　快速搭建
• 　　降低成本
• 　　社区支持维护
• 　　利于人才引进

　

其实可以看出.Net不缺优秀的开源项目，那么实施这么久让我唯一觉得深刻的印象是：缺少整合。

　　

之前我也跟不少同行讨论过甚至在面试的时候，他们觉得应该自己造一个轮子，原因各种各样，但唯独缺少了希望在开源项目基础上完善下这个原因。我也理解他们的心理，因为“优秀”的工程师应该自己写一套证明下自己。其实我认为这也许是包容心的在作祟，我们应当求同存异，学会接受已经检验过的轮子，在基础上完善您的需要，有必要还可以给社区做贡献，双赢。

原则

　　

我做技术选型的时候，坚持着三大原则，简单、适合、运维优先。

　　

在满足需求的情况下，优先选择轻量级的框架，因为轻量级总比重量级的易学习，易于扩展，易于理解源码。试想一下，有个框架什么都很齐全，但是学习曲线高，在写一个demo的时候各种踩“坑”找原因，还有可能出了问题不知道怎么解决，除了开始你初认识该框架觉得他很厉害之外，后面使用每走一步都是阻碍和吐槽。

　　

在有限的资源、人力、时间，我们更新技术的同时还要保证业务的正常开展，我会优先选择我比较熟悉的技术，我会将他们进行封装、优化、集成，尽可能的减少开发人员对技术细节的认知负担，尽可能以他们最熟悉的使用方式提供。此外，我们团队是有运维岗，如果问题由运维解决更快、更方便则优先交给运维，尽可能让开发关注数据流转与业务流程。

　　

PS：我选型的时候不是一蹴而就的，下文可能我会提到某些框架工具我没有去选择原因，并不是否认它们存在的价值，而绝大问题是这些不适用于我们团队。最后我向伟大的开源项目与其作者致敬。

微服务

　　

有一条盛传于我们行业的公式：软件 = 程序 + 软件工程。

　　

程序就是我们经常产出的算法、数据结构、脚本、框架、架构等。

　　

为什么称之为软件工程？因为这是具有科学方法论引导的、多人协作、有明确目标、有阶段性的。从以前瀑布开发再到10年前盛行的敏捷开发最后到最近几年流行的DevOps，可见开发模式也随着技术架构更新也不停的演进。我们团队选用了原型模式+DevOps模式来应对我们的微服务架构的开发。

　　

书本的教条主义我就不多说了，我对微服务的理解分为微和服务。

微

　　

如何微？微到什么程度？我借助两样东西，合理的系统架构分层与DDD思想，两者分别管理架构的横向拆分与纵向拆分。

　　

架构分层，我采用了前后端分离+多层架构，自顶向下的依赖，各司其职。

　　

DDD在最近几年非常流行，然而这并非新的技术，十几年前就已经它的出现了。随着微服务盛行，DDD的划分域的化繁为简的思想与微服务的本质-拆不谋而合，因此DDD也随之热门起来。

　　

下面是我们的架构图，这个话题在下一篇《.Net微服务实战之技术架构分层篇》重点再讨论。

服务

　　

我接下来用一段话总结一下微服务的基本需要。首先，开发人员得知道如何调用服务，那么可以从注册中心发现已注册的服务的IP地址、端口的列表，这就是服务的注册与发现；接着，我们需要知道服务下接口路径、请求与响应的格式，因此我们需要服务描述。满足前面两个条件后，我们就可以进行调用服务了，因此我们需要RPC框架进行服务通信。当服务运作后，因为服务是跨进程调用的，出问题的时候不容易定位，因此我们需要服务跟踪进行问题定位。最后，服务拆分后是独立的，因此我们要整合起来统一提供给外部调用，于是API网关作为服务的整合与网络环境的隔离

　　

由上述可见组件主要包括以下6点：

• 　　API网关
• 　　服务描述
• 　　服务注册中心
• 　　RPC框架
• 　　服务监控
• 　　分布式链路跟踪