前言
博文搜集整理，便于个人学习，最后均有原文传送门。
什么是微服务？为什么要用微服务？
简单举例：看军事新闻的同学应该都知道，一艘航空母舰作战能力虽然很强，但是弱点太明显，就是防御能力太差，单艘的航空母舰很少单独行动，通常航空母舰战斗群才是主要军事力量，你可以把单艘航母理解为的单体应用（防御差，机动性不好），把航母战斗群（调度复杂，维护费用高）理解为微服务。
大部分的开发者经历和开发过单体应用，无论是传统的 Servlet + JSP，还是 SSM，还是现在的 SpringBoot，它们都是单体应用，那么长期陪伴我们的单体应用有什么弊端？我们是面临了什么问题，导致我们要抛弃单体应用转向微服务架构？个人总结主要问题如下：
- 部署成本高（无论是修改1行代码，还是10行代码，都要全量替换）
- 改动影响大，风险高（不论代码改动多小，成本都相同）
- 因为成本高，风险高，所以导致部署频率低（无法快速交付客户需求）
当然还有例如无法满足快速扩容，弹性伸缩，无法适应云环境特性等问题，但我们不一一详谈了，以上的问题，都是微服务架构要解决的问题，至于具体是怎么解决的，我们先放到后面再聊
微服务解决什么问题，又引入了什么问题？
我们先看看微服务能带给我们什么？微服务架构的特点：
- 针对特定服务发布，影响小，风险小，成本低
- 频繁发布版本，快速交付需求
- 低成本扩容，弹性伸缩，适应云环境
我们知道一个朴素的理念，没有任何事物是完美的，任何东西都有两面性，有得必有失，那么在选择微服务在解决了快速响应和弹性伸缩的问题同时，它又给我们带来了什么问题？个人总结如下：
- 分布式系统的复杂性
- 部署，测试和监控的成本问题
- 分布式事务和CAP的相关问题
系统应用由原来的单体变成几十到几百个不同的工程，会所产生例如包括服务间的依赖，服务如何拆封，内部接口规范，数据传递等等问题，尤其是服务拆分，需要团队熟悉业务流程，懂得取舍，要保证拆分的粒度服务既符合“高内聚，低耦合”的基本原则，还要兼顾业务的发展以及公司的愿景，要还要说服团队成员为之努力，并且积极投入，在多方中间取得平衡。
对于分布式系统，部署，测试和监控都需要大量的中间件来支撑，而且中间件本身也要维护，原先单体应用很简单的事务问题 ，转到分布式环境就变得很复杂，分布式事务是采用简单的重试+补偿机制，还是采用二阶段提交协议等强一致性方法来解决，就要取决对业务场景的熟悉加上反复的权衡了，相同问题还包括对 CAP 模型的权衡，总之微服务对团队整体的技术栈水平整体要求更高。
微服务架构图
微服务系统架构图
k8s微服务系统架构图
.NET Core微服务架构图
需要的技术栈
这篇文章写的较为完善，为避免原文被删除，转载过来。
原文出处：微服务技术栈及分享计划
将涉及的技术栈将其分为如下几个阶段进行归类，后续学习分享的大方向也是如此：
对于需求阶段业务分析、测试阶段相关及最后应用阶段的服务，这系列暂时就先不涉及，而是主要针对开发技术、代码管理、应用部署、运维管理方面的技术进行汇总和学习分享；对于上图的各个阶段，可能在很多大公司将其职责划分得很清晰，但对接避免不了(DevOps)，所以了解和学习是很有必要的；如果是中小型公司，那可能开发是你、部署是你、运维还是你，技多不压身，来了就干，不服就来学。
注：不是在项目中使用以下提到的技术就是微服务，而微服务指的是业务之微，技术只是对其进行落地实现；
开发阶段
对于实现，在开发阶段涉及的组件或框架颇多，所以得花更多时间进行学习和实战，如下：
开发阶段
认证中心
当划分的服务增多时，单个服务的认证和授权显得更加冗余，更希望有一个统一的认证站点，每一个服务的认证都由认证中心站点进行处理；咱们可以从零自己实现OAuth 2.0和OIDC提供授权和认证功能，轮子肯定有人造好了，拿来就用多好，IdentityServer 4将授权和认证都有很好的实现，从而使得开发人员有更多的时间关注在业务开发上。
服务发现
当服务不多的时候，可能手动进行API地址配置，实现调用还可以接受配置复杂性，如果是对服务进行增加服务器扩展时，还得手动进行配置，那干这活的肯定要喷脏话了。如果使用Consul做服务发现，自动识别各个服务，同时还能进行健康检查，及时过滤掉不可用服务，增强高可用，显得更加智能化；减少人工配置的复杂性，还能提升服务的高可用。
网关(Gateway)
网关的主要作用是进行路由转换、统一入口、隔离内网等，当然还可以做一些服务熔断、限流、重试、缓存等相关功能。功能具体是什么意思，怎么实现？在后续的学习分享时会一一说到。而.NetCore中常用的网关为Ocelot和Kong；
- 路由转换：根据配置规则，将不同业务地址转换到对应的微服务地址上，让业务请求由对应的业务API进行处理；
- 统一入口：对于UI界面而言，只关心一个入口，即网关地址，不用和每个微服务直接打交道，降低请求访问复杂性；
- 隔离内网：对外提供地址为网关地址，内部服务通信都是通过内网，使得站点安全性增强；
- 其他功能会在后续实操中一一说到；
服务间通讯
虽然拆分成了各个小服务，但始终还是一个系统，对于一些业务依赖关系的服务会进行聚合或是通过服务间通信，将数据整合统一返回给UI层；常用的技术手段是通过Restful Api接口或是gRPC进行数据交互，然后再进行数据业务处理。
服务治理
每一个小服务也是一个程序，就有可能出现Bug、网络通信异常、服务器宕机等情况而导致服务不可用，通常我们理想状态肯定是希望其他服务不被异常服务影响，这样就需要对服务进行治理，比如失败重试、服务熔断、失败降级等，从而提升服务的可用性，避免单个异常服务导致整个系统雪崩的现象；.NetCore中会使用Polly库实现相关功能。
NoSql-非关系型数据库
通常的高并发场景下需要进行缓存和数据共享，实现高可用，而目前Redis是一个很不错的选择。对于一些文档型数据，MongoDB存储更有优势，当有大量数据时，会有一些列存储的数据库；对于搜索实现，ElasticSearch存储实现会更加符合场景；
消息队列
消息队列的三大好处：异步处理、解耦、削峰；通常在微服务系统业务处理中，遇到一些复杂业务，需要耗费较长的时间，这样给用户体验就不友好，咱们可以将涉及的业务通过消息队列分发给不同服务处理，然后及时响应给用户，业务后台异步处理，体验感觉就不一样；可能有小伙伴还会说，直接多线程不就得了，如果是这样的话，那业务可能都耦合在一块，后期维护又是一个很大问题；对于一些高并发系统，估计平时服务器都能承载请求，但是存在某一时间段高峰访问，如果请求都打到后台服务数据库，数据库可能抗不住，像这种短时段高峰的情况，可以通过消息队列进行削峰，避免高峰时刻搞崩系统；目前比较常用的消息队列有：Kafka、RocketMQ、RabbitMQ。
CAP
微服务就是分布式，既然是分布式，那分布式事务就避免不了，最终数据一致性的问题那得解决；对于分布式来说，这是老生常谈的问题了，并且提供了相关的解决方案，而在.Net中，有大神就封装了CAP，并将其开源，配合消息队列很好的实现了分布式事务控制；
Apollo
试想，如果每个服务都有一套自己的配置文件，那部署和运维是不是很头痛，而且对于一些公共配置数据也会重复在每个服务中配置使用，如果有一套统一的配置中心是不是感觉非常爽，所有服务的配置数据通过一个点进行维护和使用，不管在开发维护、部署还是运维方面，都带来便捷性；可以自己实现，也可以使用第三方的，而Apollo现在相对来说是比较火的，也有一些直接使用Consul扮演配置中心的角色；当然还有使用在K8S自带的配置中心。
后台任务
既然用到微服务项目，应该数据量也不会小，通常会做一些报表分析，数据同步等操作，而这种耗时操作不希望在业务高峰时期执行，需要在空闲时间定时操作即可，针对这种场景后台定时任务就有用武之地啦。当然不仅仅是这种场景，还有一些做业务数据重放或修复，比如一个订单在操作中异步处理失败了，可以在后台任务检查过程中，进行再次处理等；在.Net中用的相对比较多的是Quartz.Net和Hangfire。
代码管理
代码应该不用多说了，小伙伴们应该都摸清门路了，简单画个图，如下：
代码管理
代码规范
不管什么架构，代码规范一直是开发者严格要求的，开发过程中得有良好的编码规范，虽然每一个公司的要求不太一样，但最终的目的是一致的：规范化，这样在后期维护就不会花费大量的时间去研究之前代码为什么要这么写。为了规范，周期性的Code Review是必不可少的。
代码版本管理
对于代码版本管理工具，用的最多应该是git和svn了，其中对于分支的管理是非常重要的，比如临时修复线上Bug怎么办，常规开发怎么办，紧急功能开发又怎么划分处理，合理的规划代码分支不会让代码版本混乱，从而引起功能的不完整或异常；别小看这一件事，经常因为版本分支问题导致生产功能出问题的事件比比皆是，所以小伙伴开发过冲要注重哦，因为持续集成离不开代码的管理；
部署
提到部署，可能有的小伙伴会说，这不是运维搞的吗，或者说这不应该有专门的人搞吗？是的，理想是这样的，但事实就是，小伙伴不仅负责开发，还得要部署，对于职责分明的团队，至少你也得会，不然对接有一大堆的尴尬。
部署阶段
操作系统
现在部署更多的是推荐在Linux上了，像Redis、ES、nginx等都是在Linux中发挥更好的性能，而对于Linux估计有些小伙伴还不熟，甚至只是听说，还没操作，不说多的，关于开发和部署相关日常操作到时候我们来一起聊聊，高深操作可以抽时间再去研究。当然，Windows的操作到时候也能提到，毕竟现在Windows服务器也没有说不用。
持续集成(CI/CD)
老式的手动发布和部署在微服务中显得力不从心了，那么多服务，做重复操作，换做任何一个人也受不了，如果多发几次迭代，那这人就别干其他活，就负责发布妥了。想想，如果这些事自动化解决岂不完美，而Jenkins搭配代码管理软件就能很好的实现，自动拉取代码->自动构建->自动部署，代码管理软件可以自己搭建，比如Gogs，或者使用gitlab、github等都行。通过监听代码的提交，就能自动完成，想想都美。
容器化
开发和运维干架啦，一个说在我这行，一个说在我那不行， 别说那么多，先干架再说；哈哈哈，为了不允许这种事发生，容器化显得很屌，开发发布打包生成镜像，运维拉下来就直接跑，啥都一样，还有的说吗；其实主要的目的还是提升工作效率啊，现如今Docker是火的旺旺的，但K8S的弃用能否让它走下坡路，这似乎好像不太好说；
容器编排
当容器集群扩展增多时，就得有一个东西进行管理，否则扩展会显得超级麻烦，而K8S就很吃香，针对容器集群管理更好的自动伸缩、自动部署，还能搭配探针实现自修复；
运维
功能开发完了、代码也上传了、站点也部署了，用户开始用吧，后续就很轻松了；no，no，no，这才开始，应该很少有小伙伴拍着胸脯说，没事，我做的功能都没问题，绝对没Bug，好，先假设开发没问题，断电、宕机、断网咋整，这种物理问题不能避免吧，不管是做异地多活也好，还是有其他方案，至少得去弄吧；那如果是业务问题呢，排查问题更多的是靠日志了，对于微服务这种架构，有一个调用链的追踪会提供很好的辅助，来，先看看需要什么技术工具：
运维阶段
日志分析
之前单体架构，登上服务器，拷贝日志下来分析妥了，而对于微服务，这似乎不太可取，拷贝日志不仅麻烦还耗时。如果使用Exceptionless将日志统一收集在一起，是不是稍微好那么一点，再加上做一个ElasticSearch和Kibana的查询分析，是不是又加快了问题的分析速度。
链路追踪
微服务间的数据交互肯定避免不了，有一个可视化的调用链路及监控就显得更加直观，清楚的看到每次接口调用经过的服务点，对于定位问题来说也提供很大的帮助，能快速知道这次异常经过哪些服务处理，缩小范围。而用的相对比较多的是SkyWalking和Butterfly。
分布式监控系统
微服务情况下，只要一发布，就不知道什么情况，这样只有在问题发生之后，才能去排查；有没有一个监控系统，对系统和服务运行环境进行监控，能在危险范围内的时候提前给个告警，及时通知相关人员处理呢，prometheus搭配Grafana能将监控数据友好的展示和配置，从而实现对服务运行环境的监控。
电商微服务演进过程
微服务，当然核心是主题是“微”，怎么微呢？应该如何微呢？在我刚来杭州的时候接触过一个电商系统的单体架构，系统比较庞大，结合了各种电商该拥有的业务逻辑和场景， 代码也比较难于维护，前前后后接手的人也比较多，代码耦合度太高，改个业务逻辑基本上是牵一发而动全身，知乎大佬分享的关于 Asp.Net Core 中IdentityServer4 授权中心之应用实战的文章中的电商系统最初的架构图类似，如下：
那针对这个架构就有可“微”之谈了。
这里针对该单体架构可以做如下几个原则上进行“微”服务:
- 根据业务来进行拆分，一个业务一个服务原则进行拆分，做到通用性业务服务模块，这样业务之间可以做到高内聚低耦合。后面随意改动哪一块业务，只需要去改动这一块的业务微服务即可，其他业务不会受到影响。
- 一个业务模块一个独立的数据库为原则，相互平行的业务做到不需要相互依赖调用。
- 外层API网关进行业务逻辑的整合。
- 一个业务数据库一个微服务为原则。
- 结合分布式服务，可以快速版本迭代，发布平滑发布，不受时间影响，没时每刻都可以发布，无需半夜等到12点进行发布。（比较痛苦的发布，犹如三日凌空般，17年之前曾经有段时间是每周都有那么几个晚上痛苦的发布，一发布就可能是凌晨4，5点，很多时候发布完，还要经过各种测试，最后发现问题还得线上改bug，我们回去的时候别的同事已经来上班了；当时我们的技术大佬说过这么一句话：“他连续一周都没看到过他的儿子，回去的时候，他儿子早就睡着了，起来上班的时候，他儿子已经去学校了”，大家一定也有过这样的发布经历。）
按照上面的原则后，原来的电商单体架构微服务后架构图如下：
架构图粗略的画了下，能够表明意思即可，微服务、Docker、k8s那一块简要的概括，没有详细画出具体的图。
微服务总结
微服务设计其实是很早就有的设计思想，因为随着虚拟化技术的崛起，微服务可以低成本的实现，所以也开始流行和兴起。
微服务的内涵很深，其中就包括，自动化，去中心化，独立性等等，其中细节无法用一篇文章概述清楚，我们在做技术选型或者方案的时候，尽可能多去了解技术的本身和起源再结合我们业务的特点，进行更好的选择。