微服务是这几年最流行的架构，说起架构不提微服务都不好意思跟人家打招呼。最近想要再梳理一下关于微服务的知识，并且结合本人的一些实践经验来做一些总结与分享。前面会分享一些概念性的东西，后面也会使用.net来实践，一步步完成一个简单的微服务架构的小demo。
什么是微服务
其实微服务并没有统一的标准定义。微服务是一种软件架构的风格。它首先由大神martin fowler提出，2014年3月25号在他的博客上发表了一篇博客来描述了这种微服务的架构。
相对于传统的单体（Monolithic）架构应用，微服务把单个进程的应用拆分为多个单独部署的服务。每个服务对外提供一些接口来进行服务间的通讯或者对第三方提供功能。每个独立的服务甚至使用自己独立的存储技术，独立的语言技术栈。说到底微服务架构还是贯彻了软件开发中：单一职责、分而治之、解耦等基本理念，只是它把这种理念从类、类库级别提升到了进程级别。
微服务与SOA
微服务架构看起来跟SOA架构非常相似。事实上微服务架构就是SOA的一种现代化的实现方式，一次进化。虽然不能在两者之间画等号，但是他们的思想确实是一致的。
微服务与SOA之间的区别网上有很多，在此不再大段的复制黏贴网上现成的文字，简单谈谈自己的一些理解。
首先SOA大多数情况下是作用于企业内部，它通过ESB等总线技术把企业内的服务（或者称之为应用）串联起来。SOA虽然是在解耦、去中心化，但是它通常跟某种ESB技术强耦合起来，以至于ESB会成为那个最大的中心。微服务的作用范围是应用而不是庞大的企业。微服务不在依赖ESB等总线技术，服务间的通讯通过无状态、轻量级的接口实现。协议采用http、json等通用协议无关开发语言，谁都可以调用。所以相比SOA有更好的去中心化意义。
优点
上面说了这么多关于微服务的知识，那么实施微服务到底为我们带来了哪些好处？网上有很多复制黏贴的话其实我不太苟同，比如：部署简单，如果没有强大的运维团队微服务的部署显然是比传统单体应用部署难度更大了。 比如快速开发快速迭代：事实上单体应用也不用等到完全开发完才能上线。下面说下我认为的微服务的几个优点：
- 技术异构
采用微服务架构可以很方便的在每个服务中使用不同的技术栈。每个团队可以根据自身的业务情况，人员情况安排使用最合适的技术。如果我们服务业务是AI那就考虑pyhton，如果我们的人员比较熟悉JavaScript，那么可以选nodejs。当然技术的多样性也是要权衡的，不能说每个服务都撸一种语言每个都试验一把，这样未必就是好事情了。 - 扩展性
当我们的业务做的越来越大，流量越来越大的时候，需要对计算资源进行扩展。相对于单体应用，微服务可以更好的进行扩展。传统单体应用水平扩展的时候可能需要把整个应用都扩展多个实例。事实上我们的业务越来越大的时候，往往只是某个模块压力巨大。而采用微服务架构我们只需要对某压力大的服务进行水平扩展。配合现在的容器化技术能够更好的利用技术资源。 - 可靠性
由于每个服务都是独立部署，当某个服务故障的时候通常不会导致其它服务同时故障，只是丧失了部分能力。再配合服务降级、熔断等技术可以比单体应用提供更好的可靠性。 - 强模块化边界
这个概念在网上很少出现。我是在B站上杨波老师的一个关于微服务视频上看到的，对这个观点比较认同。模块化是我们软件开发常用的模式。原来我们按类、按类库进行模块化，现在通过微服务架构直接把模块服务化了，并且能独立部署运行。其它模块不在需要直接引用相关类库就可以使用它。而且实施微服务架构后会强制团队进行应用的模块化，对模块的边界进行明确的划分。当然模块的边界划分是个技术活，如果划分的不够好那就是场灾难。
缺点
这个世界上的事情都是具有两面性的。微服务除了有其优点，自然也有缺点。我们在做架构的时候要尽量处理好这些缺点，避免踩到巨坑。下面谈谈我对微服务缺点的一些看法。
- 运维难度增加
本来只需要部署一个IIS站点或者Tomcat服务、维护一个数据库，现在变成了需要部署N个不同的服务，N个不同类型的数据库。不同的服务甚至可能分散在不同的服务器上。要使这些服务正常的工作，正常的通讯，还要对其进行监控显然比单体架构时代对运维的考验提高了一个维度。没有强大的运维团队、自动化的运维工具的话微服务实施起来出故障的概率显然会大大增加。 - 分布式的挑战
微服务架构天然就是分布式的。但是分布式系统会带来很多单体架构没有的问题。比如分布式事务，数据一致性问题。本来在进程内一个锁或者在数据库开一个事务就能解决的事情，现在不得不借助分布式锁、分布式事务、数据最终一致性来处理。这些问题对开发人员写代码的时候也是很大的挑战。除了一致性的问题，微服务架构中服务之间的通信也会有很高的成本。本来进程内的方法调用变成了跨进程、跨服务的通讯。我们知道网络是不可靠的，出现故障的概率远远超过进程内调用。 - 调试，测试难度增加
由于服务之间互相依赖，在做集成测试或者调试的时候需要把所有依赖的服务、数据库等全部都跑起来。出现问题很难一次性定位到确切位置。由于服务器之间网络带宽的原因多次测试结果可能会有变动，测试的结果不稳定。 - 沟通成本提高
在采用微服务架构开发之后，团队的组织架构都可能跟着变动，团队免不了被拆分成多个小团队甚至不同部门。在公司呆过的都知道，跨团队跨部门之间沟通的成本有多大。本来一天就能修复的bug，很可能变成一周。 - 模块划分困难
我们前面说微服务把每个模块进行独立部署，采用独立的数据库。这么轻描淡写的一句话，事实上实施起来并没有那么容易。如果模块划分的不好，那么会出现非常多的跨库查询，非常多的跨库事务。本来单体架构上很简单的事情变得无比复杂。本来一句Transaction就你搞定的事情，现在可能需要先团队之间进行沟通，然后互相开接口，再使用分布式事务来完成。模块划分的一个好的方案就是采用DDD的思想进划分，但是事实上能把DDD玩好落地也不是一件容易的事。
微服务不是银弹
微服务这几年火热的很。很多公司、架构师言架构必微服务，好像微服务是包治百病的良药。不管项目大小，项目周期，人员配置，技术实力，一股脑的上微服务。见过3，5人小团队一个月就能开发上线的说要进行微服务改造。这么做怕不是微服务真的香，而是为了充实自己的简历。
微服务不是银弹，正如上面所述，微服务在享受它带来的好处的时候也是有巨大的成本开销的。它会带来组织架构上的变动，人员的变动。它大大的提高了系统的复杂性，给运维、开发、测试、调试都带来巨大的挑战。
在采用微服务架构之前最好先思考一下，真的需要微服务吗？权衡一下微服务带来的利弊再下决定。以我个人的经验来看，市面上绝大多数系统更适合单体架构，或者说没必要一上来就采用微服务架构。真正好的架构是在满足当前需求的前提下快速稳定的上线，并对后面的扩展、改造留好余地，以应对后面业务发展带来的需求进行架构的升级改造。
总结
通过以上这些铺垫我们讲了微服务的概念、微服务有哪些优点、微服务又有哪些缺点给我们带来了哪些方面的挑战。以上是我个人的一些浅薄的理解有可能有遗漏或者有错误，大家可以一起讨论一下。
作者： Agile.Zhou
随时随地看视频
