目录
我相信做技术开发的同学就算没有用过微服务架构至少也应该听说过微服务架构，为什么在当前这个数据爆炸内容丰富新技术层出不穷的时代，微服务架构会如此的🔥，到底微服务架构是什么，我应该如何搭建我的微服务架构，微服务架构会给我们带来哪些好处和挑战呢？笔者相信，通过这篇前言文章，你会对此有个大概得了解。后续专栏文章还会以实战的方式讲解常规的解决方案，教你一步一步搭建起你的微服务架构。
1. 架构演变史
1.1 单体巨石架构
单体巨石架构是所有程序员开发最开始接触的架构，也是大家最熟悉历史最悠久的架构，单体巨石架构在笔者的开发生涯中存在了很长一段时间，现在也依旧有单体巨石架构的项目在维护，哪怕新项目也有单体架构存在。
单体架构的特点是所有的代码在一个工程中，数据库里面放了所有的业务数据表，事务在一个进程中执行，可达到强一致性要求。为了让代码更加清晰好维护，基本大家最开始接触到的都是MVC模式，而为了能够应对高并发大流量访问，会在应用实例前加一个负载均衡，通过负载均衡的方式（最简单的通过nginx的反向代理）将流量转发到任一实例，所有的实例共享一个数据库。
但是对于比较复杂的工程而言，单体架构存在一些问题，以笔者公司一个历经7年的项目为例，其就是一个大单体应用，由于这七年来业务不错，不断在上面增加新的需求，导致项目越来越臃肿，暴露的问题越来越多：
1）项目结构越来越复杂，代码质量低下，很容易出现大量重复代码，且不敢随意更改
笔者公司那个大单体项目来说，刚进来公司的同事都反馈在开发过程中，发现很多重复代码，一堆吐槽，但是到自己写的时候，发现有个方法可用，但是又不完全能满足需求，一看有好多地方都引用了那个方法，这个时候很多人为了不影响原来的使用，又copy一份出来修改，周而复始，代码越来越臃肿，质量越来越低下。
2）所有人都有权限修改项目代码，很难控制代码质量
所有人都能看到所有的代码，对于公司而言，并不是那么的安全。
3）多任务并行的时候很容易产生代码冲突
这一点是我们在开发过程中经常遇到的头疼的问题，由于公司项目经常多任务并行，大家都在一个项目里开发，都从master拉了很多分支出来，到部署的时候，经常出现冲突，会花费大量时间在解决冲突下，导致开发的效率低下。笔者公司的项目最多的时候挂了20个分支在开发环境，动不动就要解决冲突。
4）难以升级，难以扩展
笔者公司大单体项目原本是用TP3.2写的，现在还是用的TP3.2，因为你会发现当项目想要升级已经变得不可能了，代价太大了。横向扩展也不方便，假设新上了一个功能，非常受客户欢迎，导致流量激增，这时候需要扩展只能整个项目再部署到新的服务器上，白白浪费资源，在这块上微服务的优势就很明显了，你可针对重的服务单独扩容，而不是整站扩容。
5）部署慢
笔者公司使用的是阿里云云效做自动化部署，由于项目太大，每次合并分支拉取代码都要花好长的时间等待，浪费时间。
基于上述的原因，笔者公司在一些合适的新项目上便采用了微服务架构，虽然微服务架构的引入带来了项目的复杂性，但是笔者觉得在开发体验上比大单体要舒服很多。
1.2 微服务架构
为了解决单体巨石架构出现的各种问题，微服务架构应运而生。微服务架构的特点是服务之间相互独立，可以使用不同的语言，不同的框架。服务之间通过http或者rpc的方式进行通信，每个服务都有自己的数据库。
首先访问通过api网关，api网关会负责进行服务治理相关的操作，如限流，服务发现（从注册中心获取服务地址），熔断等。后续专栏会讲到apisix网关的入门实践。
网关会转发请求到对应的BFF（Backend For FrontEnd）端，简单理解就是不同的端--如PC和Mobile--有不同的项目提供服务，但是BFF项目基本不执行业务逻辑，只是简单接收请求，做下简单的权限判断，数据验证操作，再请求后端服务（如用户服务、商品服务），将对应服务返回的数据聚合即可。真正提供业务逻辑处理的是在后端服务上。为什么要用BFF呢？最简单的原因就是各端展示的数据和处理逻辑可能是不一致的，由单独的项目来处理这些差异化。当然BFF不是必须的，不用BFF也可以，根据自己项目而定。
微服务架构解决了单体应用的问题了么？这个问题我们在下面的微服务架构的好处与挑战中会详细说明。
1.3 serviceMesh
serviceMesh也是最近非常火的一个话题，其基本思想是每个服务挂载一个边车应用，服务与服务间通过边车进行通信，边车拦截了服务的流量，同时在边车提供服务治理的能力。目前最火的serviceMesh解决方案应该就是istio了吧，感兴趣的童鞋可自行查看，serviceMesh不是本文重点，这里不再赘述。
2. 微服务架构的好处和挑战
微服务架构大家如此的推崇，它带来了哪些好处呢？
就笔者经历的大单体应用而言，最恼火的有三个事情，微服务架构可以更好的处理这三个问题：
1）项目臃肿，所有代码在一起，难以维护，一大个团队在一个项目中开发，经常冲突
微服务架构由于将不同的服务切分到了不同的项目中，只需要小团队维护自己各自的服务，代码质量和冲突性都大大的减少了，大大提高了开发的愉悦性。笔者公司但凡有同事从微服务项目转到那个大单体项目的，没有不吐槽大单体项目代码开发体验的，甚至出现过那个大单体应用劝退很多新人的事情。
2）难以扩展，难以升级
微服务架构的所有服务项目隔离，微的好处就在于项目要小很多，可根据自己的需求单独扩展，换框架或者换语言都会简单很多。也可针对某个单独的服务进行扩容，我相信一个系统肯定会存在某些承载更多流量更多计算资源的模块，微服务项目可以对这些模块（即服务）进行单独扩容，如果是该服务的数据库资源不足，也可单独对该服务的数据库进行资源扩容，而不是整个数据库扩容。这点上微服务的优势比单体要大很多，这也是很多大型项目采用微服务的一个重要因素。
3）部署慢
每次大单体部署都要等很久，笔者公司采用阿里云效进行流水线部署，特别是开发阶段，常常需要在本地自己调试完后部署到开发环境，这个过程很频繁，导致部署的体验非常不好。
由此可以看出，微服务架构带来的好处就是灵活性扩展性强，更好维护代码质量，项目更小更容易上手。同时，微服务架构也带来了很多的挑战：
1）系统架构变得更复杂了
微服务架构需要引入服务治理，可以用网关、sdk或者serviceMesh来做，但是这会增加系统的复杂性，你需要具备这样的技术储备才能用好微服务架构。最简单的，服务相互之间的通信需要依赖于一个服务发现的机制，那么至少，你会需要一个注册中心，这在原本的单体是不需要的。再举个例子，服务多了，配置（如数据库、redis）相互隔离，单体架构基本就是在项目里面一个配置文件就可以了，但是微服务架构不可以，如果微服务架构也采用这种方式，如果后期要更改，你会发现这是灾难性的，可能所有服务都要更改，因此需要一个统一的配置中心进行配置管理。
2）问题调试变得没那么容易
服务之间会相互依赖，比如一个服务链A->B->C，如果运营突然反馈某个页面特别慢，你需要排查所有服务链，因为每个服务都有可能出现问题，加大了排查问题的力度。因此，你需要引入专门的链路追踪工具（如zipkin）来监控链路，通过链路工具来帮你排查问题。甚至可能服务是不同的团队开发维护的，你并没有权限查看其余服务代码，如果出现了问题，没有链路工具的话你需要挨个服务通知他们技术人员进行排查，非常不方便。
3）会带来分布式事务的问题
这是笔者觉得最麻烦的问题了，原本在单体中事务ACID非常好处理，但是采用微服务架构后，会导致服务不在一个进程中，相互之间需要网络通信，CAP理论我们知道，要么选CP，要么选AP，大多数系统都会选择AP，依赖BASE理论来做最终一致性。对于分布式事务的解决方案，笔者后续专栏文章会介绍，如果现在不是特别清楚，不用着急。
4）查询将变得不那么简单
怎么查询还是问题了呢？这是微服务架构一个很大的问题，首先你不可能所有字段放在一个表里，因此，在单体中，常常会用到join查询，但是微服务架构的各个服务数据库也是隔离的，你甚至没有其余数据库权限，你没法做join，最简单的方式就是让依赖的服务提供rpc，你把需要的数据让rpc提供，自己做聚合，这将变得复杂。笔者遇到的查询问题主要容易出现在列表查询上，一个复杂的列表会依赖好多个服务，需要将很多服务的数据聚合起来，这是单体一个join就解决的问题。针对这种问题，为服务架构提出了CQRS解决方案，后续会有文章单独讲解。
5）微服务架构会带来一些运维上的麻烦
以笔者公司为例，笔者公司采用的云效做流水线部署，当前流水线有一百多条，目前面临一个问题是云效升级了，需要手动处理，没有自动化工具。目前公司只有两种方法，一种是旧的不管，还在原来的云效运行，新的才用新版云效；还有一种是逐步逐步迁移。
6) 如何做服务的划分
如何进行服务划分这是微服务架构面临的第一个问题，虽然有很多文章告诉你用DDD的思想可以指导你进行服务划分，但是笔者看过DDD相关文章和书籍后就发现，其在中小型公司还是比较难落地的，里面有很多晦涩的名词，且大多都是理论性的东西，没有实际落地的案例，估计只有大型一点的公司在用，没有相关的人才储备，建议不要随意使用。因此你需要一套自己的方法来进行服务的划分，过重或者过细的服务拆分都会是问题。
3. 我的项目是否应该用微服务架构
微服务架构不是银弹！不是银弹！不是银弹！
虽然微服务架构笔者比较推崇，但是并不是所有项目都适合微服务架构，笔者现在的新项目依然有很多用的单体。虽然微服务架构带来了很多好处，但是同时也带来了挑战，因此你需要根据自己实际情况来判断是否需要微服务架构。笔者的建议是：
1）如果你的项目不算复杂，需要快速上线，那还想什么呢，用单体架构
2）如果你们技术储备还不完善，没有微服务架构相关解决方案，那肯定用单体
3）如果你不太确定项目今后的体量和复杂度，着急快速变现，那用单体
4）如果你有长期运行该项目的计划，也可预见其今后的复杂度和体量，可以考虑用微服务架构
5）如果这个项目本身就是复杂单体重构，那肯定用微服务抛弃单体了
4. 服务治理
4.1 为什么要服务治理？服务治理到底治理什么
采用微服务架构后，服务之间的调用依赖错综复杂，如下图所示：
因此你需要一套工具来帮你管理服务间的调用，监控你服务的可用性，进行合理的日志记录等，而这些就是服务治理要做的事情。
服务治理到底治理了什么呢？
1）服务注册/发现
2）服务限流
3）服务熔断降级
4）链路追踪
5）监控指标
有了这些服务治理的机制，你的微服务才能更加稳定的运行。
4.2 服务治理的模式
目前服务治理的模式主要有三种：
1）直连模式sdk
即在每个微服务中引入sdk，通过sdk的方式各自管控自己服务的治理。好处在于程序可以有更细粒度的把控，缺点在于程序过多关注非业务逻辑的处理，过分依赖于sdk，替换和升级不方便。
2）代理模式api网关
即客户端访问api网关，网关进行服务治理，再反向代理到后端服务，如架构演变史微服务架构一节所示。代理模式的好处在于程序不需要关心治理方面的逻辑，都交给网关来处理，只需要关注业务即可。比如kong、apisix都是比较火的网关产品，你可以简单粗暴一点，想象成一个功能强大的nginx。后续章节会讲解apisix网关的实战应用。
3）serviceMesh
通过边车来治理你的服务，边车挂载在应用旁，无侵入代码，你是无感知的，你的项目甚至都感觉不到边车的存在，边车拦截了流量后再转发给后端服务。比较火的serviceMesh产品是istio，其高度依赖于k8s，只需要一条命令便可以在pod旁挂载一个边车，非常方便。但是，你需要对k8s非常熟悉，能够有k8s运维管理能力的公司才建议使用。
这三种模式并无优劣之分，可以根据自己的实际情况来选择方案。本专栏后续会专门讲解apisix网关的应用。
5. 本系列专栏内容前瞻
本专栏后续会对微服务架构常规设计模式进行简单介绍，还会重点会介绍dapr入门实战、apisix网关入门实战、事件驱动架构、CQRS、分布式事务，敬请期待。
2827
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
