微服务能力层_.Net微服务实战之技术架构分层篇

一拍即合

上一篇《.Net微服务实战之技术选型篇》，从技术选型角度讲解了微服务实施的中间件的选择与协作，工欲善其事，必先利其器，中间件的选择是作为微服务的基础与开始，也希望给一直想在.Net入门微服务的同行有一个很好的方向。在此篇重新整理了一下整个微服务项目的demo，希望对有需要的朋友起到一定的帮助：https://github.com/SkyChenSky/Sikiro

那么我在公司实施微服务的时候，也不是一拍脑袋想上就上的。刚入职公司的时候才3、4个人，产品给到我的规划只有一个很简单的系统，包含权限、客服IM、内容管理三个模块，我当时想着优先证明我们的开发能力和效率，于是使用简单的单体架构不到三个星期项目就完成了。产品在我们开发的期间把整个项目的规划和平台系统的划分给梳理了一遍，终于让我有一个很明确的技术实施方向，同时公司的人力成本预算也批了下来开始进行团队扩招。

于是我与老领导商量了一下，在现在这个情况，无论业务还是团队都具有使用微服务架构的可操作性，再采用部分DevOps的思想给与微服务实施的支持，能顺利的实施落地微服务问题不大。我们俩讨论了一番，我有良好的微服务技术储备，他有很好的运维支撑，就这样咱两达成了共识。于是我着手翻出了收藏已久的微服务中间件、架构分层、服务拆分的资料，从此开始了我的微服务实施之路。

PS:我们讨论实施微服务的时候除了以上冠冕堂皇的理由之外，其实还存有一点私心，就是现在企业招聘很多需要有实施微服务经验的人才，但是80%的项目和同行又是没有这样的实施必要与经验，这就是鸡生蛋和蛋生鸡的问题。我毫无隐瞒的说出我们的私心并不是怂恿大家冒着风险去实施，而是希望大家通过分析现在团队的组织架构、技术储备、业务架构，在条件