一、开篇
1.1 引用
时光荏苒，马上就要告别2023，迎接2024的到来！在不知不觉中，时光恍如白驹过隙，稍纵即逝。每一篇摘文都以实际案例场景出发，闲暇时间来记录这每一次mark历程，在不一样的业务实际场景下，针对项目阶段所产生的变化，制定不一样的技术方案。不论多么渺小的技术方案盘点总结，放在其对应的场景下都有着不一样的意义。
1.2 简讯
近来，随着单体架构、微服务架构、云原生、K8S、Serverless技术的不断演讲与变迁，固有人说单体好，也有说微服务好，更有甚者谈论到无服务计算的未来！
的确，在工作中能够解放双手，大幅提升研发效率，适合当下业务场景的架构不得不说的确很强！而在几个人的团队，手动管理构建自己的后端应用，也不是不行...
熟不知，在传统行业单体一体化架构盛行的今天，尚未有明确的定论！众说纷纭，尚能饭否？感叹其背后技术架构变迁的速度！当我们还沉浸在-传统的工作方式是否终将被颠覆？在研发编程领域，开发者工程师们各种AI得力助手的诞生，想必更是让我们由衷感叹其如此强悍！
实践是检验真理的唯一标准，当真正实操过后参与讨论，或许会让你有一点新发现，整理成问答实录，希望对读者在思考上有点不一样的IDea，欢迎Join谁与说，热衷拥抱新知识，旨在技术交流+心得分享->每天译点晓知识。
二、演进实录
这里，从以下几个方面进行展开-仅对单体架构VS微服务分布式架构问答实录：
2.1 架构定义
2.1.1 单体架构
a)、顾名思义就是功能高度集中、代码和数据中心化，例如一个发布包-打包成一个独立的单元，部署后运行在同一进程的应用程序。
b)、从专业的角度来讲，部署运行在同一进程内的应用程序，称之为单体架构应用或单块架构应用。
2.1.2 微服务架构
a)、从字面意思上来看就是很小的服务，通俗来讲，类似于古代著名的发明-活字印刷术，每个服务都是一个组件，通过编排组合的方式来使用，从而真正意义上做到独立、解耦、组件化、易维护、可复用、可替换、高可用、最终达到提高交互质量、缩短交互周期的成果。
b)、从专业的角度来讲，微服务架构是一种架构模式：即提倡将单体应用划分为小型的服务单元，服务之间相互协调、配合为用户提供最终价值。每个服务运行在其独立的进程中，服务之间采用轻量级的通信机制互相沟通（通常基于HTTP协议 RESTful API 进行资源访问与操作）
2.2 架构演进历史
我们都知道从单体架构演进到微服务架构模式，并不是一蹴而就的，这里以开发一个实战项目为例： 初期，业务需求较为简单，互联网行业技术也不是像现在如此日新月异，从市场调研->需求分析，评审...
在经过研发"攻城狮"们"挑灯奋战"，不断努力冲刺的阶段后，项目就如期而至的上线了，上线后深受用户的青睐，好评如潮。但随着业务的不断发展，多方客户的接入-定制化需求，以及同行各方竞争压力的加持下，无疑给项目带来了强烈的冲击，在研发任务如此紧迫的前提下，来不及规划整体架构，不停地赶功能。当然，也的确能够一个部署包就能解决各客户的一些定制化需求，但随着需求的改动频繁，用户量的骤增，出现严重的性能瓶颈，包括所有业务应用功能都在同一个数据库上操作，连接数能力有限，数据库也捉襟见肘，性能可谓急骤下降...
研发、部署、测试、运维也愈发困难，即使改变一个很小的需求，也要发布整个应用。此时，虽不能全盘否认初期阶段的成果，那是否需要在思维模式上加以改进？妥协性舍取，团队成员职责单一，各司其职，独立开来。琐碎的业务需求不加以改变，系统建设愈庞大，不断推翻重建，愈困难重重...
诚然，此时不搏何时搏，意识到了问题，接下来，就看看我们如何去给出相应的解决方案来应对？
于是乎，腾出精力梳理业务需求，项目框架技术架构，将关联性比较强的业务作功能集中，关联性较弱的业务间去耦合性，抽象出公共的业务核心框架能力。当然做出改造的前提下，需要有足够的精力与资源来做这个事情...
在经过研发童鞋的持续coding后，模块化，组件化，服务化也体现出了雏形，各业务板块，独立开来，业务功能职责也较为单一，单体应用划分为小型的微服务单元，各自发展，互不影响，又可相互协作，数据库也是访问各自业务范畴内的数据，应对频繁的需求变动，轻松自如，哪怕是一个很小的改动，也可以特定地更新某个板块即可，水平扩容也较为便捷，独立部署...
2.3 架构对比分析
2.3.1 单体架构
优势：
a、易于开发
b、易于测试
c、易于部署
d、易于水平伸缩
劣势：
a、维护成本不断增长
b、持续交互周期较长
c、可扩展性差、数据库连接能力扩展有限
d、技术单一、并发能力有限
e、重复功能建设不利于业务沉淀可持续发展
f、有一定 协作成本，系统启动及业务响应慢
g、耦合性较高、部署包庞大臃肿
2.3.2 微服务架构
优势：
a、技术异构性
在微服务架构中，每个服务都是一个相对独立的个体。如开发一个社交平台，可能使用文档型数据库来存储帖子的内容，使用图数据来存储朋友圈的这些关系，将每一块的性能都发挥出来。
b、弹性
在单体架构中，一个部分出现问题，可能导致整体系统的问题，而在微服务架构中每个服务可内置可用性的解决方案及功能降级方案。
c、扩展
在单体架构中，需要扩展，往往是整体进行扩展，而在微服务架构中，可以针对单个服务进行扩展。
d、简化部署
在单体架构中，大型系统即使修改一行代码，也需重新部署整个应用系统。而在微服务架构中，每个服务的部署都是独立的，可以更快地对针对特定部分的代码进行部署。
e、与知识结构相匹配
若团队系统规模越大代码库越大，且当团队是分布式的时候，微服务架构可以将架构与组织结构相匹配，避免出现过大的代码库，从而获得理想的团队大小及生产力。服务的所有权也可以在团队之间迁移，从而避免异地团队的出现。
f、可组合性
在微服务架构中，系统可能会开放很多接口供外部使用。当情况发生改变时，可使用不同的方式构建应用，而整体化应用程序只能提供一个非常粗粒度的接口供外部使用。
g、对可替代性的优化
在单体架构中，若删除系统中的上百行代码，因单块系统中关联性很强，可能不知道发生什么难以想象的事故。而在微服务架构中，可以在需要时轻易地重写服务，或删除一些不再使用的服务。
劣势：
a、分布式系统的复杂度
b、运维成本与部署自动化
c、DevOps与组织结构
d、服务间依赖测试与管理
综上，对比来看：
单体架构：前期易开发、测试、部署。
微服务核心特点：小，且专注做一件事情，轻量级的通信机制，松耦合、独立部署。
单体架构向微服务架构的演变更像是一个单位或者公司的发展过程，起初，从最开始的小公司，到后来的大集团。而大集团可拆分出多个子公司，在每个子公司下，又都有其独立的业务、员工，它们各自发展，互不影响，合则威力无穷。
三、思考延伸
前沿&拓展
No Silver Bullet Essence and Accidents of Software Engineering。
似乎没有一套万能且灵活的方法论，因为业务场景模式各有所不同，不同时代下的产物也不尽相同，当计划赶不上变化的时候，但我们还是需要能够具备提前有所作出改变，应对策略的能力。
像当今很火的云原生，那么多云厂商都在做云原生，是否需要，有必要统一标准？想必云原生计算基金会-CNCF...
现在绝大部分系统都做了前后端分离，通过前端访问，后端按业务功能做了横向拆分，各个服务都实现其单一的业务功能，一个系统通过一个个微型的服务单元来组合成一个完整的业务，实行可插拔式插件。简言之，一个系统可能需要开发成数个微型的服务。
大道至简，如何能够让复杂的事情变得更简洁些？"简单的事物，一般是美而和谐的"，换个维度思考，以生态学上的细胞为例，系统不再是按业务功能做横向微服务拆分，而是按访问服务的对象做垂直拆分，这样是不是在水平方向上极大地简化了访问路径。而每一个"细胞"为访问对象服务，当然，也可以做功能繁殖。每个细胞都是微小的单元，职责单一，动态组装可插拔，积木式拼接，可复制清除，也可以按某一个区域划分归类...
四、总结
回顾&憧憬
的确，DT&AI时代，包括AI类创新性产品的出现，这无疑给开发者带来了巨大的冲击。但是，作为开发者的我们，应以积极的态度去面对，拥抱技术，提高我们自身的知识技能，学会借助并运用工具，从而更好地适应技术的发展，结合实际场景灵活应用。
首先，凡事都有一个过程发展阶段，只有各自经历才能够更深刻理解，同时，有的事物也需要度量...
中小企业基于微服务开发有无必要，需结合业务场景，用户体验，研发速度维护成本等来分析，技术不能为了技术而技术，过度的设计可能在某些阶段造成极大的浪费。
每一个不同的架构方案跟随着当下业务而演进，适合才最合适，以各自实际的具体业务场景，作统计分析，我们可以从这些点出发，比如：业务的复杂度，系统的并发程度，项目需求变更是否频繁，整个系统的效率、伸缩扩展、稳定及可靠性等等。
