系列文章
- .Net微服务实战之技术选型篇
- .Net微服务实战之技术架构分层篇
- .Net微服务实战之DevOps篇
- .Net微服务实战之负载均衡（上）
- .Net微服务实战之CI/CD
- .Net微服务实战之Kubernetes的搭建与使用
- .Net微服务实战之负载均衡（下）
- .Net微服务实战之必须得面对的分布式问题
- .Net微服务实战之可观测性
前言
本文于 2022.6.22，首发于ITPUB 官方公众号，作者陈珙，未经授权禁止转载。如需转载，请联系 ITPUB 公众号。
开始前我跟大家分享个自己的小故事，大概1年多以前，我给某个企业培训微服务实战，既然是实战当然是从实施落地出发。但是培训完毕后，甲方却反馈我对微服务的概念讲得太少了，他们压根不知道什么回事。开始我以为他们只是谦虚客气一下，因为我认为已经到了202X年了，微服务或多或少都了解一些，但是并非如此，经过我和其他同行沟通来看，我的想法确实以偏概全了。
所以我趁着这次和ITPUB 合作，把以重新理解微服务从他的过去、本质出发跟大家分享自己一些见解。这篇文章原本1万7千多字，经过和DTCC的韩老师沟通后，最终拆成了两部分，下星期会再发另外一篇。
温故而知新
不少同行，对于“什么是微服务”，都在各平台发表过相关理解、看法等。随着这些年的技术发展，只要涉及到“微服务”这三个字已经不再纯粹，几乎无论是什么方向技术，或多或少会跟微服务扯上关系蹭蹭热度。当然，也恰恰基于此，使得我为何重提何为微服务，并且单独拿出从多个方面结合我的个人见解，想与大家深入探讨。
先开头这里，就抛出我自己的一个观点吧，我并不认为非要把技术弄得多复杂，才显得多牛X。再复杂的物品也是由一件件简单的物品组件形成的，而适当的返璞归真才能看清楚事物的本源。
若要想要更清晰地了解、理解、搞清楚“微服务是什么”，我认为只需要认真看懂一篇文章就足够了——2014年马丁·福勒个人博客发表的《Microservices》博文（https://martinfowler.com/articles/microservices.html）
但是，马丁·福勒所著的作品多数是高度总结的，假如你没有亲自实践过，他的作品与思想理解起来相对比较困难，因为他的叙述总体比较抽象。当然，这不影响我自愿重复多次的阅读他的作品——温故而知新。
因此该篇我不会照搬翻译，或是人云亦云，而是会从《Microservices》原文和其他书籍收集回来的资料并结合我的个人见解，来叙述微服务的What、When、Why。
这篇文章没有微服务的How，可能您看完了也不知道应该怎么去实施微服务，但是关系不大，因为我一直坚信，如果你能把某件问题的来龙去脉，清晰无误、通俗易懂地传达给别人，该问题已经解决了70%，那么剩下30%就是寻找解决方法的路上。方法远要比遇到的问题要多得多。如果您对具体的微服务实践有兴趣，可阅读完该文后请移步到《.Net微服务实战》（https://www.cnblogs.com/skychen1218/p/16352324.html）进行扩展阅读。
本篇文章，我将通过选择微服务的原因、微服务的小历史、微服务的特性和我对微服务的个人见解多个角度，分享我对微服务理解的What。你可以总体浏览下大小标题，快速过一遍。抑或是期间挑自己更为感兴趣的部分，直接跳到那里看。
选择微服务的原因
说到这，我想先问这样一个问题，你选择微服务的原因有哪些呢？可能这问题的回答会百花齐放，无论是哪种原因，促使我们选择微服务终须一个或多个的理由。凡是做任何一件事情，都要有目的性，不可盲目，否则只能是毫无价值的冒进。因此在这我给大家分享下我选择微服务的理由。
单体应用的优与劣
在早期的开发，单体应用给开发提供了很多的便捷性：
- 开发简单方便；
- 项目管理集中；
- 进程内调试，排查、定位问题更加便捷。
随着团队与业务规模的增加，单体应用的缺陷就会越发的明显，以我个人实践经历，如果希望引入微服务，我认为得满足以下任意3点，则可以考虑选择微服务：
- 并行开发的代码冲突；
- 加载、编译、部署项目缓慢；
- 代码耦合性越来越高；
- 需要统一数据读写入口；
- 无法按需扩展。
我早些年遇过10人并行开发共有两三百个项目的解决方案，不论是每次项目加载、编译、部署，其实都非常花时间。只要并行开发就会存在冲突，修改的代码资源越集中，出现合并冲突概率还越大。
在单体应用里，我们会以“库”的方式形成组件，以此来进行单元复用，如果在同一个解决方案里共享复用，使用与修改的自由度会更高。
任何事情都会有利弊的，随着项目的发展，参与的人越多，迭代的频率越高，那么“库”的职责边界就越不清晰，代码耦合也会越发严重。而且因为项目多了，为了方便复用，不同的“应用”引用相同“库”的情况也自然会变多，这样就导致了数据的读写入口扩大，假如数据出了问题：
- 不好定位原因。
- “库”出了问题，相关引用的应用都得重新发布或回滚。
微服务的优点
微服务的优点有不少，但是我认为核心优点是独立部署与协议统一，而其他的优点都是基于两者之上进行扩展的。因此本小结会着重叙述这两点，剩下的优点我将会在下文结合微服务的特征再进行详细叙述。
微服务其中之一的优点——独立的进程部署，以软件工程的角度出发，从物理层面约束了团队职责，刻意地划分了业务之间的边界，每个开发组（人员）都会清晰了解各自的领域与职责，使得大家优先思考清楚需求的修改点，该由哪个业务组负责。
另外其中一个优点——数据的读写访问统一协议，以技术设计的角度出发，数据的读写操作都被封装成Http API以此隐藏了技术细节，能大幅度降低调用端的技术人员，对非所属业务模块的细节关注，从而把他们注意力转移到所属的业务层面，减少认知负担。
此外，还可以避免非所属业务的技术人员对数据结构做出了不恰当的修改。
总得来说，微服务从工程化的层面解决了不少单体的“老大难”的问题，但是，既然没有“银弹”的存在，那么“新”的技术同样也会带来更多新的挑战，具体的新问题，我将单独拿出来放到新的一篇文章，跟大家详细地分享下，接下来会跟大家分享一下微服务的过去。
微服务的一些小历史
虽然微服务无论是从理论还是实践上解决了不少单体的“老大难”的问题，但是它并不是一门新的技术，它的诞生年份得追溯到2005年，而它的设计思想得追溯到Unix的哲学思想，因此，要想了解一样事物的本质，那么就应从它的历史发展说起。
维基百科截图
提到微服务，马丁·福勒这个名字肯定不能忽视，不少人认为马丁·福勒创造的微服务。对于该错误的认知，我认为我有必要应该重新说明下。参考了维基百科（https://en.wikipedia.org/wiki/Microservices#History），我把微服务发展历史整理成了时间线。
上文我们可以总结出三个核心关键点：
- 微服务的起源最早追溯到2005年；
- 微服务不是由马丁·福勒他本人创造的；
- 那篇举世闻名2014年写的《Microservices》原文是由詹姆斯·刘易斯和马丁·福勒他们两人共同合作编写的。
虽然说微服务架构并非马丁·福勒所创造的，但是称《Microservices》这篇文章是推动微服务的崛起的缘由，一点都不为过，而詹姆斯·刘易斯和马丁·福勒两位对微服务的盛行起到了非常关键的作用。
微服务的特点
上文结合了维基百科分享了微服务的小历史，同时也为微服务、马丁·福勒和《Microservices》原文三者之间的关系，做了个简单叙述，以便大家更加清晰的认识。
原文的九大特征
既然已经了解了微服务的过去，那么接下来得了解它是什么。马丁·福勒曾经在《NoSQL精粹》写过一句话，他并不喜欢给某件东西下定义。因此在书里，他对于NoSQL总结几大共同特征，而拥有这些特征的存储系统可以称之为NoSQL。
同样，他在《Microservices》原文里，对于微服务架构风格也总结出了微服务具有的9种特性（详细请看下文），而我结合了资料与实践提炼了一下关键字也总结了4个关键特征：
对于原文里的九种特征，还有一段更加精炼的总结。大家看的时候可侧重看我提炼和加粗的关键字，稍后我会结合原文与我的个人总结说一下，以便于帮助你快速抓住分享要点。
原文：