术语

–微服务

–云化

–分布式

–高并发

–高可用

架构角色

• 探索者
• 设计师
• 倡导人

到底如何区分什么是架构、框架、模式和平台 ？

设计模式<框架<架构<平台，从复用角度讲，设计模式是代码级复用、框架是模块级复用、架构是系统级复用、平台是企业应用级复用。

模式:分为代码模式、设计模式、框架模式这些

• 设计模式有不同的分类，如下
  • 创建型设计模式，如工厂方法（Factory Method）模式、抽象工厂（Abstract Factory）模式、原型（Prototype）模式、单例（Singleton）模式，建造（Builder）模式等
  • 结构型设计模式，如合成（Composite）模式、装饰（Decorator）模式等
• 框架：也有叫构架的，一般等同于ＭＶＣ、MVP、MVVM这种。

举个栗子，农村要盖房，架构就是：你得考虑自己的经济实力、喜欢什么样的房子、有什么要求，选哪个靠谱的施工队。选好了之后，比如说要盖楼房，那么框架就是施工队的模式，有的施工队先这样做再那样做，而有的却相反，反正能把楼给你盖起来就行。模式就是局部的具体实现，比如说门这样安、窗户这样。

目标

达到最佳的功能和服务表现

资源利用率

灵活的开发、部署、运行、维护和创新

安全性、稳定性、可靠性等质量属性

影响结构的因素

利益相关者

开发团队

架构师

环境其他因素，比如冲突，隐性需求

Typical Design Trade-offs

功能和可用性

性能和可修改性

成本与鲁棒性效率和可移植性

快速开发vs.功能性

成本与可重用性

向后兼容性与可读性

架构：做一个基准让软件能够不断完善。架构本身在做的事情就是衔接软件从无序的需求变成有组织、有序的软件设计实现的中间转换环节。==>注意架构的很多关注点都是来自于架构本身驱动的因素和非功能性的点（architectural driver）：性能、使用中的高可用、

质量属性：

• 易用性高——一个中等业务水平的储蓄所人员能够在5个工作日内熟练掌握本系统80%功能

问题？可修改性和性能，是否可以可以同时满足？ A: 这两个很容易冲突

近几年的毕业论文——把功能实现了，但非功能性需求就只是列了几个点。非功能性需求反应了这个系统关注的哪些指标点。同时要考虑非功能性需求之间的优先级，要体现了哪个目标是高的，是低的。这种优先级的，

单点–>分布式==》集群化的，集群化服务的一些点就慢慢会形成一个高可用的架构，比如主备、热备、温备、冷备，还有一些通过集群化的方式来实现的高可用，比如多活、两地三总线。

多实例化应用：提高冗余数据虽然提高了可用性但是增加了安全性的影响、应用层管理实现方式：统一身份认证（统一的认证中心，避免了每个点的认证），权限层、认证层、网关层

组件间信息通信来探活，保证组件的可用性

性能：

• 优先级调度，有优先能执行
• 有足够的资源

安全

• 拦截请求
• 加密、认证

大型商业银行的主要特征：

• 24小时不间断的高效核心银行系统
• 跨渠道、跨业务线、跨区域的集成服务能力
• 集团一体化架构模式下的差异化、个性化支持能力

每一层都有不同的关注点，每一个关注点都有各自的解决方案，比如接入层有高并发的需求，业务处理层有安全可靠的去求。将关注点分层以后。

优势：每一个层能看地更清晰，并且更好地关注自身地处理方式。

劣势：层次层次交互过程中地trade-off问题

从quality地角度考虑，分布式是在解决高并发的访问，实现系统更好的应用性与交互性

核心银行系统的非功能性需求

• 规模
• 性能
• 安全性
• 可用性和弹性
• 运维管理

用户接入平台技术架构

所有接入的模块都不止一个，不管是tcp、http、还是身份认证的还是可视化管理的，都是通过增加多个实例来实现高可用。==>主备、多活

应用平台->应用系统->系统进程->技术模块

关键技术组件模块：

• 数据访问接口
• 后台进程运行模型
• 容错平台架构
• 数据可视化
• 公共服务框架
  • 监控管理
    • 统一的数据格式
    • 监控数据定义
    • 统一展示
  • 日志管理
  • 时间管理
• 撮合应用框架
• 行情处理应用框架
• 交易控制架构

大型网站系统特点
高并发，大流量
高可用
用户分布广泛
需求快速变更
发布频繁
海量数据
安全环境恶劣
渐进式发展