微服务你可能没有真正实践过，但你一定听说过。虽然已经2022年了，但是这个词还是很火的，搜一下google索引就可以看到。起源“微服务”一词起源于2011年5月在威尼斯附近的软件架构师研讨会上对架构风格的讨论。2012年5月讨论组决定将这种架构风格命名为“微服务”。FredGeorge在同年的一次技术会议上分享了他的微服务实践，说微服务是一种细粒度的SOA，不过是MartinFowler写于2014年的博文《 Microservices 》，原文链接如下：https//martinfowler.com/articles/microservices.html。从此，微服务家喻户晓，2014年以来GoogleIndexforMicroservices一路飙升。与微服务对应的是单体架构。让我们来看看单体架构是什么样子的。单体架构大多数人应该从单体架构开始软件开发。对于.NET程序员来说，从最早的WebForm，到后来的MVC，再到现在的前后端分离，后端使用.NET的WebAPI，将整个项目的代码放到一个解决方案中，发布或者直接替换整个目录，或者更新变化的dll文件。包括到现在，这种单体架构应该还是占了很大的比重。无论存在什么，它都必须是合理的。单体架构有其优点：易于开发，.NET程序员只需要使用宇宙中最强的IDEVS即可。调试方便。在开发阶段，所有项目都在一个解决方案下，项目可以直接引用，断点可以到达任何地方。运行起来很方便，编码完成，一个F5搞定。部署方便。不管是以前的IIS部署，还是现在的容器部署，都涉及到一个发布目录。但是随着产品的功能越来越复杂，代码也会越来越复杂，团队的数量也会越来越多。这时候单体架构会带来一些问题：因为代码库非常臃肿，从编译、构建、运行到测试的时间会越来越长。技术栈几乎是有限的。比如一个.NET项目，基本都是用C#开发的，不太可能混用其他语言。横向扩展不方便，只能扩展整个程序来满足所有模块的需求，资源利用率很差。它不够敏捷。当团队成员越来越多时，他们都在同一个代码上修改、提交、合并，很容易造成冲突等问题。一个小小的变化点，很容易引起系统问题，导致系统崩溃。因为冲击点多，测试成本会很高。缺乏可靠性，我们曾遇到过序列化问题导致CPU占用率过高，导致整个系统瘫痪。微服务架构采用微服务架构可以很好地解决上面提到的单体架构的问题。微服务的核心是构建一个松耦合的分布式系统进行解耦。一个庞大的单体系统被拆分成几个小服务，每个服务可以由一个小团队维护。团队会更敏捷，构建和发布的时间会更短，代码也更容易维护。不同的微服务团队可以采用不同的技术栈。例如，工作流引擎使用.NET，规则引擎可以使用Java。一些全新的模块更容易采用新技术，人员流动和补货更灵活。每个服务通常使用独立的数据库，代码或数据库层面的问题不会导致整个系统崩溃。易于扩展非常重要。如果监控发现流程引擎压力很大，只能对这个服务进行横向扩展，可以更好的利用服务器资源。以上所有都是好处，但没有任何技术是灵丹妙药。微服务在解决问题的同时，也带来了更多的问题。1.开发调试变难了，需要借助日志或者使用一些远程调试工具。2、在单体架构中，模块之间的调用都是进程内的。添加类库的引用后，就是本地方法的调用。微服务的独立部署会涉及到进程之间的通信。3、线上问题往往需要多个服务团队协同解决，会出现互相推诿的问题。4、在分布式系统中，事务、数据一致性、联合查询等比单体更复杂。5、持续集成、部署、运维的复杂度也大幅增加。6.服务越来越多，客户如何找到这些服务？7、进程内访问没有网络问题。拆分服务可能在同一台机器的不同进程，更多的时候是不同机器的不同进程，网络问题导致服务不稳定？为了解决这些问题，各种中间件和框架应运而生，这会带来更多的学习成本。在.NET技术栈中，会用到如下中间件：服务注册与发现：Consul。网关：豹猫。电路降级：Polly。服务链接跟踪：SkyWalking或Twitter的Zipkin。配置中心：Apllo。认证中心：IdentityServer4。在Java中，也有SpringCloud、SpringCloudAlibaba等全家桶套件可以使用。你想切换到微服务吗？从单体到微服务，是一个权衡取舍的问题。记住不要跟风。从我的经验来看，可以分为两类：做企业级系统。做互联网系统。大部分企业级应用都是项目交付的，客户关系维护的很好。第二和第三阶段可以在未来完成。当然，也有一次性交易。关键点之一是要快。单从速度来看，单体架构的开发、调试、部署是最快的。从客户的角度来看，只要能满足业务，是单体还是微服务其实并不重要。做互联网应用，也就是我们常说的SaaS，也可以分为两种情况：1、将现有的私有化部署系统（单体架构）改造为支持SaaS的模式。我不建议一出现就进行大刀阔斧的微服务改造。可以在代码的结构上做一些调整，比如按照域拆分目录，不同域之间的调用可以重新抽象。目的是为了以后向微服务架构转型。当团队的技术栈越来越丰富的时候，比如以前只有.NET，现在有的模块使用了Java。这个时候已经在向微服务架构发展，但是粒度比较大，还需要引入一些相应的中间件，如服务网关、服务发现、服务间通信等。2、从零开始搭建SaaS系统。互联网系统和企业级系统有很大的区别。如果说企业级系统更注重功能需求，那么互联网系统除了功能需求外，还需要关注非功能需求，比如：水平扩展、限流降级、日志跟踪、预警、灰度release等。即使一开始因为时间关系是单体架构，我觉得也应该是单体微服务架构。随着不断的迭代和发展，会根据实际情况逐步拆分。如果时间多的话，可以从一开始就按照微服务架构进行分离，但是粒度不能太小。总结和解决经常提到的三高问题（高并发、高性能、高可用），一个核心思想就是拆分，分而治之，所以微服务绝对可以解决我们的很多问题，同时也是发展方向。微服务的实践需要立足于当前的实际情况。单体跑的好就没有问题，不要为了炫技而去改造微服务。如果决定实现微服务，首先要设计单体架构，让代码遵循面向对象的设计原则。否则，即使形式上变成了微服务，你也尝不到微服务的甜头。
