go-微服务的设计概括
一、微服务到底是什么？
初学者很容易把微服务和分布式混为一谈，但其实二者之间存在非常大的差异，我个人认为主要有以下几点：
- 分布式主要是一种技术手段，用来保证多个相同的进程能够共同工作而不出错。采用各种复杂的技术手段(比如选举机制、数据同步机制、传输机制、心跳机制等等很多手段)来保证数据一致性、可靠性、分区容错性(CAP理论)。使得它们能够共同工作，使得存储、吞吐量等各项性能乘倍提升
- 微服务更多的是一种设计，通过业务职能将一个项目划分为多个服务，每个服务专注于自己的职能即可。有一个理论叫小即是美，微服务的划分将一个大模块划分为多个小模块，每个团队负责一个小模块会更加精细，并且更加灵活，所谓的灵活我们接下来会讲解。
- 在实际业务场景中，微服务和分布式又是密不可分的。如果公司选择了微服务架构说明公司的业务体量已经达到了一定规模，那么考虑到性能和高可用性一般同一个服务会有多个实例，同时存储组件也会有采用分布式的组件来存储。
二、微服务到底有什么好的？
并不是所有项目一定要使用微服务，只有当业务的复杂性和体量到达一定程度后，微服务才能发挥它的作用
我们想象自己是一名大厂架构师，公司正在经历从单体到微服务的转型。面对如此庞大、复杂的业务系统，我们会面临什么问题？
- 访问量暴增，一个单体服务即使它的物理机非常牛逼，仍然可能支撑不住导致宕机
- 数据量暴增，目前我们所有的数据都在一个数据库中，如何进行扩容
- 由于迭代太快，可能一些团队写了一些错误代码，导致整个程序不可用
- 每次新写几个功能都要部署整套单体系统才能够进行测试
针对问题一、二，简单粗暴的办法就是复制。复制几个相同的单体服务和数据库放在不同的物理机上，来提高性能。这种办法确实是短期最有效的，用来应急没有问题。但是长期来看这存在严重的浪费问题。有以下几点：
- 大部分时候流量暴增都是针对几个热点模块，并不是所有的模块访问量都大，也并不是所有模块的数据表都需要扩容。粗暴的复制会浪费很多设备
- 如果采用微服务的方式，只对热点模块和对应的数据库进行复制能够更加精准解决性能问题，且能够大大减小资源浪费
针对问题三、四，单体架构几乎无解，可微服务则能够很好的避免。
微服务中哪怕出现严重bug也只会影响自己的服务，并且上线都是逐步上线，没问题了才全部替换，能够大大提高整体的可用性。
测试的时候只需要部署该服务以及依赖的服务即可，不需要全部部署
三、微服务需要注意哪些问题？
微服务并不是银弹能够解决所有问题。它会增大系统的复杂性并严重依赖于基础设施。
- 设计微服务需要考虑服务的划分以及协同工作，最重要的是服务之间涉及到网络传输，需要考虑非常多的异常情况
- 微服务需要有配套的基础设施，比如链路跟踪、分布式日志、性能指标采集、动态扩缩容等等
- 需要考虑服务之间的通信问题，比如通信协议、api设计规范(非常重要)、打造一个统一的标准
- 需要考虑服务注册、发现
- 需要考虑分布式带来的问题
等等很多
所以在业务还不复杂的时候，使用微服务是非常不明智的选择
四、微服务设计原则
去中心化原则：
微服务设计里面尽量不要有流量中心和数据中心。
比如我们通常会有一个BFF层用来并行调用多个微服务拿到数据进行组合，那么我们应该根据业务将BFF层拆分成多个BFF组件，否则所有接口的流量都走一个BFF容易导致宕机，也很容易因为一个地方的失误导致整个BFF不可用。
第二个就是数据中心，应该为每个服务设计一个数据库，这样当需要进行扩容伸缩时不需要对全部数据库进行扩容，更有针对性。
4.1 微服务架构
Gateway：提供认证授权、流量控制、负载均衡等通用支持。常见的手段是将认证得到的用户信息放到header中传输给BFF层
BFF: 并行访问微服务接口组装数据返回给用户，注意的是BFF应该提供粒度较大、较通用、并且风格统一的接口，用来减小前端人员调用的复杂度
