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