[理论]第1章-互联网架构演变过程

软件架构认知升级

一切架构都应从业务出发

企业中架构的演进都应以业务发展为主导。明确演进的缘由才能更好的掌握架构。

那么如何做到认知升级？

一个问题：架构师到底需要学什么？

高并发新系统/秒杀?

那么如何学习？搜索资源。

high concurrency architecture

scalable architecture

Tip: 当检索一些问题时，可以换一种语言逻辑去检索

有什么区别呢？

为前者更注重细节、讲技术，后者更注重整体、讲规划。

没有好坏只有认知层次的区别

合格的架构师应该只拘泥于具体技术或者说炫技，更要懂得业务整体规划架构。要考虑架构的可扩展性，监督各种非业务指标。

那么什么是可扩展架构?

可扩展的体系结构是一种可以纵向扩展以满足增加的工作负载的体系结构。

可扩展的架构 (jenkov.com)

得到了认知升级

综上所述，由更专注于技术的 高并发架构 升级到更专注于业务的 可扩展架构 就可以认为是架构师思想的一次认知升级。

统一了思想接着开始聊架构了

何为软件架构设计

什么是架构师？

架构设计 师

什么是架构设计?

架构设计的定义

架构设计是人们对一个结构内的元素及元素间关系的一种主观映射的产物。架构设计是一系列相关的抽象模式，用于指导大型软件系统各个方面的设计。

--百度百科

定义过于宽泛不利于理解，并根据定义找到相关学习资源。

缩小范围

系统架构设计 -> 软件系统架构设计 -> 领域软件系统架构设计

这个时候我们明确了缩小了目标范围更便于找到需要的学习参考目标。

也说明了架构设计是一个复杂的问题。

复杂与简单

• 简单问题

可以简单的理解为通过搜索引擎搜索出的并能得到明确答案的问题都可以认为是简单问题。

• 复杂问题

千人千面，例如不同人眼中的哈姆雷特，豆浆甜的好好喝还是咸的好喝，PHP是不是最美的语言。 架构设计更多是根据业务、当下技术及人员情况就等进行综合取舍的博弈结果。

可以参考 Ralph Stacey Model 认同和确定性矩阵

推荐阅读 www.sohu.com/a/334942937…

那么复杂问题该怎么学习呢

学习其根本

橘生淮南则为橘，生于淮北则为枳

-- 晏子春秋

对于橘子来说就是明确为菊的因素即光照、水分、土壤和温度等，调控这些基础的因素，从而得到橘。

对于架构设计来说明确其之于成功软件系统重要的因素，或调控或实现这些因素，从而得到成功的软件系统。

为何软件架构设计重要、如何做

• 系统的骨构：（做）业务建模、数据建模

• 影响软件的非功能属性：（做）定义详细的非功能属性需求
• 是提前决策的过程、有助于发现问题：（做）发挥集体的智慧，为架构决策提供方向
• 使系统有了统一的通讯机制：（做）系统相关规范
• 可复用的系统建模：（做）总结复盘，为后续设计提供经验。
• 利于与利于相关方沟通，获取更多资源:（做）通过讲解让非技术领导了解系统关键部分
• 有利于评估开发成本：（做）为功能模块提供复杂度评估
• 影响企业组织架构划分：（做）系统分层

单体架构及演变进程

老生常谈的架构演进

核心都是业务驱动的演进，或者说资本驱动。

推荐阅读 segmentfault.com/a/119000001…

单体架构（Monolithic）

• 优点:

  • 简单并且易于部署:所有代码都在一个解决方案。
  • 技术难度低:对程序员要求低。
  • 易于调试和测试:调试不需要配置复杂的依赖，只需要运行代码就可以调试和测试。
  • 易于监控:当发生故障/错误时，更容易确定问题发生在哪里，因为代码都在一个项目中。

• 缺点:

  • 项目变大后难以维护:项目开始时，容易维护，但随着时间的推移，应用程序可能会变得更大，这可能难以管理。
  • 部署时要停机维护:当单体发生变化并需要部署时，整个应用程序将在部署期间不可用。
  • 不适合大团队:团队人数过大时则开发效率非常低。
  • 可扩展性差:单体可以扩展，但只能扩展整个应用程序。如果应用程序仅在应用程序的某些特定部分收到过多的请求，则不能仅扩展该部分，需要扩展整个应用程序。此外，并不总是可以使用水平缩放，需要垂直缩放，这通常更昂贵。

面向服务架构（ServiceOriented）

• 优点:

  • 服务可重用性:将通用模块变成服务，提升高发效率。
  • 平台独立:服务独立于平台，服务可以使用不同的编程语言编写。
  • 易于扩展:服务相互独立，因为可以较容易替换和更新，而不会损害其他服务。
  • 可用性高:任何人都可以轻松使用这些设施。
  • 并行开发:SOA不仅支持分层，而且只需要关注接口，可以多团队并行开发。

• 缺点:效率降低:服务过多的调用，导致效率降低。

  • 调试和测试困难:需要部署内容较多，而且可能想互依赖，调试和测试困难。
  • 业务建模要求高:对商业流程的计划要求高。
  • 投入大:硬件、团队人力资源和研发管理等。

微服务架构（MicroService）

• 优点

  • 招聘变容易

    模块化设计，让开发人员承担单一职责，使得程序员的可替换性变高。当前的主流的框架，开发人员都熟悉，减少培训人员成本。

  • 数据存储灵活

    相比SOA和单体架构，微服务可以将数据保存在多个地点，也可以用不同的数据库载体来保存。

  • 提升部署速度

    微服务架构可以轻松地与敏捷、DevOps和CI/CD保持一致。

  • 多种编程语言混用

    同一个项目，可以使用多种编程语言，比如涉及并发可以使用C++或GO，涉及复杂业务可以使用Java。

• 缺点

  • 服务拆分困难

    拆分到什么程度算是成功的拆分，一直很难把控。

  • 测试和调试复杂

    类似SOA，需要相互依赖，增加调试难度。而且有时候由于中间件配置导致查问题复杂，比如网络延迟和负载均衡。

  • 可用性降低

    系统稳定性会取决系统中质量最差的那个服务。

SOA 与 微服务对比

	SOA	微服务
服务粒度	粗粒度	细粒度
易于部署	需要重新创建和重新部署整个应用程序	每个服务都可以独立构建和部署
远程调用成本	通信开销低	由于远程调用增加而导致的高通信开销
部署速度	部署速度慢	快速、持续和自动化的部署
持久性	SOA中的所有服务共享数据存储	每个服务都可以自由选择自己的数据存储
人员要求	由于可能需要了解整个应用程序的范围，因 此很难让新开发人员加入	无需了解整个应用程序的范围，易于新开发人员入职
多语言编程	支持	支持
通讯方式	ESB(使用SOAP或WS*等标准)	能使用 REST,gRPC等轻量级协议进行通信.
可扩展性	规模化可能具有挑战性	通过使用容器具有极高的可扩展性
主流	NO	YES

那种好？

当下最优解 微服务！

Serverless 是什么？

待单独介绍，发布后会补上连接。

ServiceMesh 是什么？

待单独介绍，发布后会补上连接。

Serverless、脚手架、ServiceMesh的目标

升微服务开发和维护效率，最终还是微服务架构。

微服务与分布式的关系

微服务架构是分布式架构的一种实现方式。

分布式架构是一种架构风格，微服务是一种架构模式。至于什么是架构风格与模式下篇文章详细讨论。

总结

• 认知升级：业务为主导的软件架构，设计可扩展的系统
• 精准定义：通过精准定义找到行业参考资源
• 比较架构找到当前适宜深度学习的架构：微服务
• 微服务与分布式的关系：微服务架构(架构模式)是分布式架构(架构风格)的一种实现方式。

个人心得

扩宽视野->以义为始->层层深入->得己所需

例：以定义的角度去分析架构设计，一层层将目标具体化，从而找到寻找目标的方式。

找其原因->为其根本->调其根本->得其善果

例：找到架构设计重要的因素，实现或调节因素，得到成功的软件系统

知其优劣->横向对比->结合时境->得出结论

例：知道每种框架的优劣，横向对比优劣，结合现实的情况，得出微服务最适宜的结论。

PS:这一章从总结到变成自己的理解输出的过程消耗了不少时间，希望有其价值。

本文很多观点来自于Mike老师的课程学习过程中，可以关注他的公众号"Mike谈技术"了解更多