系统架构之感想
时下软件界，架构界吹起了微服务之风，软件从传统的CS到BS，从单体到多服务器，再到现在的微服务；很多伙伴们也跟着技术潮流越来越多的在关注和学些或使用微服务解决项目中遇到的很多问题。本人也在软件行业20来年了，所谓活到老学到老，从软件开发，到软件设计，到软件架构，种种心路历历在目。不过现在我要说的并不是我自己的从业经历，而是我最近在架构方面的学习和领悟所感分享给大家。
架构定义：
软件架构是一个用于指导系统实现的草图，草图包括架构图和设计文档，草图越详细对系统实现的指导意义就越重要，且贯穿于软件的整个生命周期。
软件生命周期中架构设计的体现：
设计期：架构设计是重中之重。需求导向，架构先行。具体工作包括：系统拆分，技术选型，技术验证，接口规范，集成方式，技术规范，部署方案，运维方案等等。
实现期：确保各项技术规范和技术指标的执行落地，保障高质量的代码；指导研发任意和解决各类技术问题，提高研发团队效率；制定测试的技术性方案，包括自动化、性能、安全等方面；配合准备部署环境，运维实施方案落地。
运行期：发布上线相关基础工作，包括是否使用持续集成，自动化发布等技术；运维基础性工作，自动化运维、监控等相关技术。
架构的目标和方法：
目标：可控性与拆分；复用性与抽象；非功能性需求九维目标：高性能，可靠性，稳定性，可用性，安全性，灵活性，易用性，可扩展性，可维护性。
方法：4+1视图模型。用例视图或叫场景视图（用例图）；逻辑视图（类图，交互图，时序图）；开发视图（组件图和包图）；进程视图（活动图）；物理视图（部署视图）
架构风格发展：
单体架构：整个系统的所有功能单元部署到同一个进程中。可以分为：
简单单体模式：代码层面没有拆分，所有业务逻辑都在一个项目中。
MVC模式：按职责划分为模型（Model）视图（View）控制器（Controller）
前后端分离：前端逻辑和后端逻辑独立编写。
组件模式：系统每一个模块拆分为一个子项目。
类库模式：把被依赖系统作为组件库，打包到当前系统使用
分布式架构：
面向服务架构（Service Oriented Architecture）：通过讲业务系统服务化将不同模块解耦；落地方式分为：分布式服务化（Dubbo），集中式管理化（OpenESB）；两大基石：RPC（RR请求响应模式，OneWay单向调用模式，Futrue异步模式，Callback回调模式）和MQ（点对点和发布订阅模式）。
微服务架构（Micro Services Architecture）：由一些独立的服务共同组成系统；每个服务单独部署、独立运行在自己的进程中；每个服务是独立的业务；分布式管理。
SOA和MSA的区别：微服务是一种经过良好架构设计的SOA解决方案，是面向服务的交付方案；微服务更趋向于以自治的方式长生价值；微服务与敏捷开发思想高度结合在一起，服务的定义更加清晰，同时减少了企业ESB开发的复杂性；微服务是SOA思想的一种提炼；SOA是重ESB，微服务是轻网关。
微服务面临的问题：防止雪崩（请求压力大限流）；功能降级（故障时有容错手段保障整体应用）；幂等（多次下同一订单结果永远同一个）；缓存（变化小读取量大的数据）；超时；熔断（下游失败产生一定概率后熔断开启直接返回失败）；服务隔离（上游能隔离故障）；可伸缩（根据业务场景扩容和缩容）；数据库拆分（独立服务提供单独的数据库）；可扩展（小改动代码增加新功能）。
微服务领域驱动设计
引入原因
微服务架构包含2个维度：技术维度和业务维度。技术维度交给基础架构设计者和微服务框架保障；业务维度的关注点是领域驱动设计所擅长的。
定义
领域驱动设计是一种方法论，建立以领域为核心驱动力的设计体系。将要解决的业务概念和业务规则转换为软件体系中的类型及类型的属性和行为，通过合理运用面向对象的封装、继承、多态等设计要素，降低系统业务复杂性，且更具扩展性。
概览
设计阶段
战略设计阶段：从问题域和架构2方面考虑。
问题域：核心领域、子领域；限界上下文、上下文映射。
结构方面：分层架构、六边形架构、CQRS（Command Query Resonsibility Seperation）模式
战术设计阶段：对每个限界上下文进行设计，用领域模型表达复杂的领域知识，模型要素包括：实体、值对象、聚合、领域服务、领域事件、工厂、资源库、应用服务。
设计过程
战略设计界定边界和粒度；战术设计验证模型有效性、完整和一致性；两者形成一种演进式的迭代设计过程。
