架构阅读笔记8
通过引用“好高骛远”和“高瞻远瞩”，我们知道前者讲的是追求，而后者是行动，当我们把高远的目标只作为一种追求，而不付诸于实践的时候，就是不切实际；当我们把它变成“时时顾看”这样的行动时，我们就渐渐地变得有眼界视野了。所以志存高远并没有错，只是要切忌不务实。作为人生的哲理，重要是务实行动，做行动上的巨子。
从需求到实践之间需要系统架构。架构有许多方法，分类为：工件驱动的方法；用例驱动的法；模式驱动的方法；领域驱动的方法。经典的架构沿用RUP迭代思想。关键需求决定架构，结合软件架构风格和通用知识选择最关键、影响最大的子系统分析设计并产生构件。组合就是定义构件接口，构件作为一个封闭的功能实体，对外提供交互接口，并通过连接件将构件连接起来形成最终的软件架构描述。由分析、描述、选择、构造和组合构成。大致将架构思维可以分为：分解、集成、分离、复用、分层、模式、抽象、结构化、迭代、勿做过度设计这几部分，按照这个思维方式来设计系统架构。分而治之则是通用方法。
分解，对于应用层，系统划分未若干子系统，低耦合存在，在业务角度可以将单个应用独立为应用单元（应用单元是无状态的）。数据层，对数据库进行垂直拆分按照子系统纬度进行分库和水平拆分按照业务纬度进行分表；但是进行分库分表中要避免分布式事务，实在无法避免可利用消息系统来进行规避。代码结果层，则从下至上分别为：数据访问层、业务逻辑层（又或称为领域层）、表示层。分解原则，单一责任原则、适当的边界、业务分层、颗粒度递增、非唯一依赖。技术原则，则是部署独立性、动态扩展、领域和应用解耦、避免产生频繁的跨库查询、避免产生频繁的分布式事务。治理原则，则是在业务分层的基础上，根据业务细分规则，对微服务分组；各个分组之间通过API网关集成；通过API网关实现级轻量级消息路由，鉴权；运行时管理，如服务降级，限流，监控等可在API网关实现，让微服务功能纯粹；避免通过数据库集成；避免部署多个版本来兼容。
分解的过程，基本顺序是先业务后技术，通过多维度多层次的分解将关注点分离。业务需求分解，首先是从业务需求入手，寻找业务需求中的分解维度，将架构从业务需求层面进行大粒度的分解，首先是从业务需求入手，寻找业务需求中的分解维度，将架构从业务需求层面进行大粒度的分解。适当考虑企业战略，这样可在一定程度上保证架构分解的合理性。业务功能需求分解，通过对业务流程和用例进行分析，根据功能职责，进行垂直和水平分解，识别出业务功能或业务服务，将它们归类到子系统中相应模块中去。