这是架构师训练营学习的第四周，主要内容是互联网系统架构（参加下面的思维导图）。这周学习最大的收获就是，进一步加深了“架构是为业务服务”这一理解，所有的架构都是为了解决你的业务问题。复杂的、架构设计良好的大型互联网系统，往往都是由小网站慢慢发展演化来的。互联网系统业务所需要的高并发、高可用，推动了其架构的演进。但传统行业的互联网应用（toB）往往对高并发要求不高，有几千几万的用户已经是非常多了。那么传统行业互联网应用架构会遇到哪些问题，会怎样发展呢？
本文以一个能源行业公司的数字化转型为背景，介绍其一个互联网产品/系统的发展演化，关注其遇到的问题与对应的架构方案。
从单机版软件到网络版本
能源行业的toB软件，在五年前大部分基本都是桌面软件。客户都是买很多软件授权，A工程师把数据用A1软件处理后交给B工程师用B1软件再处理，最后由多人多软件来完成一项复杂任务。在数字化转型和云计算概念大火时，公司决定开发一个互联网系统，把整个工作流程全覆盖，以帮助所有工程师高效协作，快速完成任务。
开始阶段，业务人员挑选了一个相对较小的子任务，进行可行性研究开发。组件了两个开发组，一个叫框架组，负责认证授权系统、数据库系统，一个叫应用组，负责在框架基础上开发具体应用。系统的整体架构很简单，在公有云上租了几个虚机，把应用和SQL Server数据库部署上去。两个组人员少、交流多，做出来的东西也需要一起发布（强耦合）。
从单业务模块到多业务模块
业务模块间数据耦合过多，都依赖于SQL Server数据库。一个业务模块改变数据结构，所有相关业务模块都需随之更新。
数据库负载变重，所有业务都需访问数据库。
部署耦合，每次版本更新需协调所有业务模块/业务开发小组。
新业务新模式，微服务
新业务以微服务方式开发，拥有自己的MongoDB数据库，可独立部署在PaaS（Microsoft Service Fabric）中。
为降低业务间耦合，系统引入消息队列Rabbit MQ来协调各业务服务间的通信。
为保障响应速度，新业务都以集群化的方式部署，利用PaaS的水平伸缩来进行动态扩展。
计算密集型业务，分布式缓存
计算密集型业务服务的引入，带来了很大的性能问题。为此，专门在云上开辟出计算专用资源，避免其他资源被占用。引入分布式缓存，提高性能、减少重复计算（以空间换时间）。
需要部署到不同的国家、不同的“云”
出于数据和安全的考虑，不同的客户对系统部署有不同的需求。很多国家对能源数据有不能出国的限制，所以倒逼系统必须能部署在客户所在国家。整个系统在往docker+kubernetes上迁移，以便能实现不同云上的部署。
----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
