《周志明的软件架构课》学习笔记 Day4

1.主动学习

微服务时代

Microservices: a definition of this new architectural term
现代微服务的概念：微服务是一种通过多个小型服务的组合，来构建单个应用的架构风格，这些服务会围绕业务能力而非特定的技术标准来构建。各个服务可以采用不同的编程语言、不同的数据存储技术、运行在不同的进程之中。服务会采取轻量级的通讯机制和自动化的部署机制，来实现通讯与运维。

第一，围绕业务能力构建（Organized around Business Capabilities）

第二，分散治理（Decentralized Governance）

第三，通过服务来实现独立自治的组件（Componentization via Services）

第四，产品化思维（Products not Projects）
产品化思维的意思就是，我们要避免把软件研发看作是要去完成某种功能，而要把它当做是一种持续改进、提升的过程。比如，我们不应该把运维看作就是运维团队的事，把开发看作就是开发团队的事。开发团队应该为软件产品的整个生命周期负责。开发者不仅应该知道软件是如何开发的，还应该知道它会如何运作、用户如何反馈，乃至售后支持工作是怎样进行的。这里服务的用户，不一定是最终用户，也可能是消费这个服务的另外一个服务。
第五，数据去中心化（Decentralized Data Management）

第六，轻量级通讯机制（Smart Endpoints and Dumb Pipes）

第七，容错性设计（Design for Failure）

容错性设计，是指软件架构不再虚幻地追求服务永远稳定，而是接受服务总会出错的现实。
第八，演进式设计（Evolutionary Design）

第九，基础设施自动化（Infrastructure Automation）

微服务追求的是更加自由的架构风格，它摒弃了 SOA 中几乎所有可以抛弃的约束和规定，提倡以“实践标准”代替“规范标准”。

服务的注册发现、跟踪治理、负载均衡、故障隔离、认证授权、伸缩扩展、传输通讯、事务处理等问题，在微服务中，都不再会有统一的解决方案。

后微服务时代

虚拟化技术、容器化技术
针对同一个分布式服务的问题，对比下 Spring Cloud 中提供的应用层面的解决方案，以及 Kubernetes 中提供的基础设施层面的解决方案

服务网格（Service Mesh）

无服务时代

无服务的愿景是让开发者只需要纯粹地关注业务：一是，不用考虑技术组件，因为后端的技术组件是现成的，可以直接取用，没有采购、版权和选型的烦恼；二是，不需要考虑如何部署，因为部署过程完全是托管到云端的，由云端自动完成；三是，不需要考虑算力，因为有整个数据中心的支撑，算力可以认为是无限的；四是，也不需要操心运维，维护系统持续地平稳运行是云服务商的责任，而不再是开发者的责任。

与单体架构、微服务架构不同，无服务架构天生的一些特点，比如冷启动、 无状态、运行时间有限制等等，决定了它不是一种具有普适性的架构模式。

备注

摘自极客时间 - 周志明老师的公开课《周志明的软件架构课》 <- 极其推荐大家阅读~>

2. 写在最后

作为普通的程序员，微服务架构对我们来说确实很友善，如果从事架构，技术架构者的第一职责就是做决策权衡，有利有弊才需要决策，有取有舍才需要权衡。如果架构者本身的知识面不足以覆盖所需要决策的内容，不清楚其中的利弊，也就不可避免地会陷入选择困难症的困境之中。

后续也需要好好学习，认真了解Kubernetes

优秀留言
软件架构的发展方向，是慢慢得把与业务无关的技术问题，从软件的层面剥离出来，在硬件的基础设施之内就被悄悄解决掉，让开发人员只专注于业务，真正“围绕业务能力构建”团队与产品。

把复杂的问题交给计算机硬件解决，使得开发人员只用关注业务，让开发越来越简单，同时能够调用的计算机资源越来越强大。

这也符合奥卡姆剃刀原则：“如无必要，勿增实体“。

如果问题能让计算机自动解决，就不要麻烦人类。：）