day5-架构选型

前言

又是这种大话题，就当记下笔记吧。

技术选型

技术选型选的是什么？

技术选型的目标

1. 降低开发成本
2. 提高研发效率

技术选型需要考虑什么

1. 团队能力
   例如，团队都是java出生，这时肯定不能贸然用go语言开发一个新的模块，团队的学习成本和本身团队的技术栈都是很重要的。
2. 业务本身的特点：用户量、访问量、业务量
   技术本身就是为了业务服务的。技术的不断发展本身就是因为有其实际的业务场景而不断催生的解决方案。所以，在任何时候，我们都应该围绕着当前需要解决的业务场景本身的特点来选择技术。这不，强如阿里也是从单一架构起步的，其原因相信很大一部分是因为其业务特点，使单一架构就能够满足业务需求。所以千万不要硬着头皮跟着头部公司选架构，一定要结合自身的业务特点。如果要我说的话，我觉得可以预估三到五年后，你的业务能达到什么程度，按照这个程度来设计。

架构技术箱

架构的历史发展

1. 单体架构
   适用于用户量不大，业务规模比较小的业务系统。可以简单粗暴的直接加机器来获得更好的业务支撑性能。
   优点：简单粗暴（架构简单、测试简单、部署简单）
   缺点：服务不可靠（某个单一功能点的问题就可能影响整个服务）。随着业务复杂度的增加，耦合度变高，开发维护成本变高，增加机器获得的性能提升边际效应锐减。
2. 分布式架构（垂直架构）
   优点：减轻单体架构的耦合度，便于切分后的项目独立发展。按需扩容。
   缺点：RPC方式五花八门，公共功能都需要重复造轮子，单点登录麻烦。
3. SOA架构
   由于垂直架构拆分力度通常都很有限，虽然业务的继续发展，某些业务系统依然会面临原来单体架构的问题。因此基于分布式架构的思想：分而治之，把服务力度拆分的更细一些。通过统一的RPC来公用公共功能。于是，SOA架构通过一个ESB总线来统一RPC层。
   优点：松散耦合、可灵活拓展、可重用。
   缺点：接口耦合、系统切分颗粒度
4. 微服务架构
   按照单一职责拆分微服务，这意味着每个服务都足够小，能够处理的业务范围明。即在服务层面的高内聚。
5. 云原生架构
   由于微服务拆分的颗粒度比较细，因此不可避免的加剧部署负担。于是，催生了云原生解决方案。在微服务的层面上，搭载容器化技术和容器编排技术，实现快速一键部署。

这些都是随着业务的不断发展壮大，日益复杂而催生的升级版解决方案。

小结

云原生方兴未艾，微服务如火如荼正当时。但是建议大家在做架构选型时，还是要基于业务本身的特点来进行选择。杀鸡不需用牛刀。此外，如果我们在类的层面都没有把单一职责用好、理解透彻，如何在拆分微服务的时候，能够做到恰到好处呢？并且，个人觉得，微服务最好不要一步到位，刚开始的时候，颗粒度粗一些没关系，服务职责明确了就行。然后是分包-包的职责也很重要，这涉及到后续的二次拆分。但如果上来就拆分的很细，等到后面发现职责边界模糊，RPC调用比较混乱的时候再想回头重新整合拆分，困难比较大，代价也比较高。