优秀架构师修成之路( 六 ) _架构师

1、优点：

开发简单，集中式管理；
基本不会重复开发；
功能都在本地，没有分布式的管理和调用消耗。

2、缺点：

效率低：开发都在同一个项目改代码，相互等待，冲突不断；
维护难：代码功功能耦合在一起，新人不知道何从下手；
不灵活：构建时间长，任何小修改都要重构整个项目，耗时；
稳定性差：一个微小的问题，都可能导致整个应用挂掉；
扩展性不够：无法满足高并发下的业务需求。

3、常见的系统架构遵循的三个标准和业务驱动力：

提高敏捷性：及时响应业务需求，促进企业发展；
提升用户体验：提升用户体验，减少用户流失；
降低成本：降低增加产品、客户或业务方案的成本。

4、基于微服务架构的设计：
目的：有效的拆分应用，实现敏捷开发和部署。

文章插图

关于微服务的一个形象表达：

文章插图

X轴：运行多个负载均衡器之后的运行实例；
Y轴：将应用进一步分解为微服务（分库）；
Z轴：大数据量时，将服务分区（分表）。

5、SOA和微服务的区别：

SOA喜欢重用，微服务喜欢重写；
SOA喜欢水平服务，微服务喜欢垂直服务；
SOA喜欢自上而下，微服务喜欢自下而上。

Serverless架构1、思想：无服务器是一种架构理念，其核心思想是将提供服务资源的基础设施抽象成各种服务，以 API 接口的方式供给用户按需调用，真正做到按需伸缩、按使用收费。
2、优势：消除了对传统的海量持续在线服务器组件的需求，降低了开发和运维的复杂性，降低运营成本并缩短了业务系统的交付周期，使得用户能够专注在价值密度更高的业务逻辑的开发上。
3、内容：目前业界较为公认的无服务器架构主要包括两个方面，即提供计算资源的函数服务平台 FaaS，以及提供托管云服务的后端服务 BaaS 。
函数即服务（Function as a Service）：是一项基于事件驱动的函数托管计算服务。通过函数服务，开发者只需要编写业务函数代码并设置运行的条件，无需配置和管理服务器等基础设施，函数代码运行在无状态的容器中，由事件触发且短暂易失，并完全由第三方管理，基础设施对应用开发者完全透明。函数以弹性、高可靠的方式运行，并且按实际执行资源计费，不执行不产生费用。
后端即服务（Backend as a Service）：BaaS 覆盖了应用可能依赖的所有第三方服务，如云数据库、身份验证、对象存储等服务，开发人员通过 API 和由 BaaS 服务商提供的 SDK，能够集成所需的所有后端功能，而无需构建后端应用，更不必管理虚拟机或容器等基础设施，就能保证应用的正常运行。

文章插图

三个less感觉很好：

Codeless 对应的是服务开发，实现了源代码托管，你只需要关注你的代码实现，而不需要关心你的代码在哪，因为在整个开发过程中你都不会感受到代码库和代码分支的存在。
Applicationless 对应的是服务发布，在服务化框架下，你的服务发布不再需要申请应用，也不需要关注你的应用在哪。
Serverless 对应的则是服务运维，有了 Serverless 化能力，你不再需要关注你的机器资源，Servlerless 会帮你搞定机器资源的弹性扩缩容。

架构师在完成上述架构设计后，最终是需要协同利益相关方一起按项目化运作落地拿结果，那么应该如何保证利益相关方在项目落地的满意度，如何保证按照架构很好的拿到项目成功的结果呢？架构管理能力是架构师非常重要的能力。
架构师管理架构双赢模型

文章插图

架构结果管理

文章插图

优秀架构师必须掌握的几种架构思维架构的本质是管理复杂性，抽象、分层、分治和演化思维是我们工程师/架构师应对和管理复杂性的四种最基本武器。
最近团队来了一些新人，有些有一定工作经验，是以高级工程师/架构师身份进来的，但我发现他们大部分人思维偏应用和细节，抽象能力弱。所以作为团队技术培训的一部分，我整理了这篇文章，希望对他们树立正确的架构设计思维有帮助。我认为，对思维习惯和思考能力的培养，其重要性远远大于对实际技术工具的掌握。