系统架构发展
一、K.I.S.S 原则
计算机的一个经典说法，所有的UNIX哲学浓缩为一条铁律就是 “K.I.S.S”原则，即 keep It Simple，Stupid。就是说一个程序只做一件事，并且做好这件事。若我们能做好一件事，那一件一件去做，就你能做好所有事吗？现实是残酷的，在这个行业中，我们经常做不好一件事，或者说不容许长久的做好一件事，那就更谈不上好做更多事了。
业界用了好多方法，如结构化分析设计、面向对象分析设计、重构设计、领域设计、敏捷软件开发等等，其目的只有一个，就是如何高效高质量的做好一件事。所谓的IT建模，也就是围绕做好一件事来进行的。
二、系统架构发展的四个阶段
概括起来，鸡血藤架构发展历程主要有四个阶段：第一个阶段是单体应用的C/S客户服务器时代，第二个阶段是分布式组件化应用阶段，第三阶段是SOA时代，第四阶段是微服务架构时代。
每一个时代出现的架构和技术都要适应当时业务应用的深入发展。
2.1 单体应用的C/S客户服务器时代
这一时代的主要内容是C/S模式和B/S模式的服务端应用，这些模式主要还是面向功能来实现业务的，一般采用的设计方法包括：结构化分析与设计方法，原形发等。这时候的软件系统架构都是单一架构，由于一个业务功能形成一个完整的闭环应用，若在内部完成的很好，一般情况下没有太复杂的逻辑。这种系统一般被称为信息化系统，更多的体现为数据库应用系统。
编程的一般做法是先根据数据流程图设计好数据库物理模型，然后根据数据库结构形成所谓的CRUD操作。这样就形成一整套系统
这种架构模式下，开发团队的所有成员采用同样的开发工具或编程语言来开发，功能实现的代码集中在一个发布包中进行集中部署和发布。业务逻辑实际上是数据库系统表的增删改查及其外延。
这种方式易于开发、部署和测试，存在的问题是：
（1）程序代码汇总在一块，无法协调开发。
（2）系统高度集中，非核心问题也可以导致整个系统瘫痪，稳定性差。
（3）程序耦合度高，后期维护复杂，功能扩展困难。
（4）业务变更和整合会导致重构整个系统，迭代时间长。
（5）对开发语言的依赖性强。
整个时代的标签是： 客户服务器模式，单一架构，类库架构，结构化分析方法和设计，关系型数据库开发，SQL语句，安装包等。
2.2 分布式组件化应用时代
随着系统业务的不断丰富和完善，糟糕的业务耦合和混乱的功能调运，重复的软件开发和大量的低层次应用，让巨大臃肿的系统变得越来越难以管理，同时还要更加困难的高质量交付。故需要把代码级别的高内聚，低耦合，易拓展升级到系统架构级别。
这时候，软件复用，集成化和组件化逐渐流行。面向对象设计和基于构建开发是这个阶段的典型特征。设计和开发的重心从数据库设计数据库层面转移到业务逻辑层面，同时引入了一个新的概念叫应用服务器。
与此同时，业务也进行了分层，即把业务逻辑都放在这个应用服务器的容器中，业务客户端只负责输入/输出的UI界面。
例如，传统web开发中的MVC模式就是将应用划分为三层，分别是负责界面渲染和展示模型中数据的视图层，负责封装应用数据和业务逻辑的模型层，处理视图和模型之间转换关系的控制层。
在集成化构件模式下，架构已经分层并且每层都可以按照构建来进行组合，采用面型对象设计和基于构建开发，但对基础框架还有一定的依赖性，分布式技术也开始成熟起来。当时流行的有三大技术平台：EJB，COM和CORBA，同时产生了一个名称——中间件。
其中Java和COM/DCOM/COM+都锁定了开发语言，而CORBA是多语言兼容。这一个时代是java流行的时代。java通过各种规范标准来诠释编程世界。
在IT开发过程中，这个时代出现了极限，敏捷等开发方式。极限编程（XP）是一种灵巧的轻量级软件开发方法，而敏捷开发以用户的需求进化为核心，采用迭代，循序渐进的方式进行软件开发。
这个时代的标签是：EJB，CORBA，组件，UML，设计模式，应用架构设计，业务模型，敏捷开发，极限开发。
2.3 SOA（面向服务架构）时代
早期企业内部管理信息化系统都是独立化烟囱式应用，这就造成了“信息孤岛”。对此，IT界就推出了EAI(Enterprise Appliaction Intergration,企业应用集成)方案。
一方面企业内部各个独立的IT系统要实现数据共享，另一方面，企业要求与外部系统实现更灵活的通信。
EAI就是基于各种不同平台、用不同方案建立的异构应用集成的方法与技术。其目的就是实现各个系统之间的相互访问和数据共享。
EAI涉及界面集成，应用集成，数据集成和平台集成等多个层面，每个层面都有对应的技术和应用实现，如SOAP，JVC，JMS，XML等。尤其是流行的web service技术。但是EAI没有解决本质问题。
此时引入了SOA，对于EAI来说，基于SOA的企业应用系统可以随着企业业务的变化而逐渐变化，能够实现“柔性化”的软件系统。服务化架构基于垂直切分的系统，将功能划分为服务，并且通过完整的服务治理规范和标准化的通信协议，容许各个服务间进行服务组合，满足了系统业务功能和服务管理需求。
SOA提倡将复杂的应用程序按照不同的，可重用的功能划分为不同的服务，服务是一个粗粒度的可被发现的软件实体，基于这些不同服务并可以在服务的基础上进行组合、集成、编排和建模。其重点在于设计一系列松耦合、粗粒度、可被发现的服务，并提供服务的高可复用性、扩展性和可用性。
2.3.1 SOA的实现技术
（1）web service
可以说web service技术的出现，推动了SOA从概念走向落地。随着java、C#等面向对象的编程语言、应用服务器的发展，以及SOAP、WSDL、UDDI等配套技术的出现，SOA得到了进一步发展。
web service技术的目的在于解决分布式计算中统一异构系统的通信协议。web service有一些列协议规范来支撑。最基本的协议包括SOAP（消息传输协议）、WSDL（服务描述协议）和UDDI（发布和搜索web服务协议）等。另外还有如何在SOAP中使用XML加密或XML签名来保证消息传递的安全协议WS-Security、可信赖传输WS-Reliablity以及事务处理WS-Transaction等规范，以保证传输的安全性和可靠性。
（2）Message Queue
消息队列服务解耦了系统之间的依赖，从技术上看，消息队列为系统提供异步处理的能力，解决了并发同步调运引起资源紧张所形成的的瓶颈等问题，为不同系统的数据交换提供了统一的交换传输介质。
（3）ESB
ESB基于业务整体架构进行搭建，提出了最基本的链接中枢，实现了企业信息系统不同服务之间的通行和整合。
2.3.2 SOA存在问题
SOA也存在很多问题：
（1）复杂的ESB总线处于核心位置；
（2）整个系统的架构并没有实现完全的组件化和面向服务。
（3）学习和使用门槛依然偏高。
（4）在服务交互过程中，传输性能比较厚重。
（5）相关协议中有太多的没有价值的信息，降低了系统性能，不用于高性能、多并发的网络应用。
（6）实施过程对规范和标准的要求比较高，加大了实时和推广的难度。
为了解决这些问题，标准和规范必须统一，但是统一的难度极大。因此这一时间可以用臃肿的、庞大的、僵化的状态来描述SOA服务。
而SEST模式采用JSON的数据格式，使用HTTP动词PUT，GET，POST和DELETE来描述创建、读取、更新和删除操作。这是一个SOAP技术的替代品。同时这个技术也拉开了SOA演化为微服务的序幕。
2.4 微服务架构时代
互联网的应用在技术上提出了一些高要求，如高可用、高可靠、高并发等。在业务上提出了些复杂要求，如快熟相应需求、迭代反馈等。但是在互联网场景下，对于整体系统某些构件的某些特性有特殊的要求，还必须针对系统的不同构件进行处理与隔离。
互联网的需求变化快和用户群体庞大，如何从系统架构的角度出发，构建灵活、易扩展的系统，并且随着用户量的增加，如何保证系统的可伸缩、高可用性，这称为系统架构面临的挑战。因此，如何找到一种更有效、更灵活、更能适应当前互联网时代需求的架构体系方式，已经称为业界关注的焦点。
随着通行技术的完善，轻量级REST技术、容器技术的出现，轻量级通行协议标准、服务注册中心、云服务平台等IT基础设施的完善以及PaaS云，IaaS云的普及等，微小服务架构能很好的弥补SOA的缺陷。
当然，微小的服务架构也有软件工程和软件过程管理的要求，包括极限开发、敏捷开发等开发方式，以及持续集成、持续交付、开发部署一体化（DevOps）的要求。
同时服务治理技术和方法也丰富起来。
在技术层面上。微服务有最初的项目型微服务软件，如Netflix，进入开源的微服务框架平台，如Spring Cloud平台，然后进入运维型微服务框架平台，如Kubernetes等。各种基于微服务应用的基础设施技术、自动化技术、开发平台、管理工具、运行框架、底层技术平台层出不群。
在基础设施层面提出了服务网络，带来了服务智能自治模式，如挎斗。
在云平台结合方面，微服务与基于容器云的云原生架构很好的融合在一起。
在微服务运行环境中，提出了serverless和Faas架构并在应用中进行推广。
在业务分析层面，以前各种有一定深度但却被忘记的建模分析和设计管理思想也活跃起来，如领域驱动设计、CQRS架构、六边形架构、Clean架构等。
在应用实施层面，CI/CD和DevOps首先响应微服务应用带来的流程转变，接着组织、团队、人员、文化等都在影响并推进微服务应用的发展。
在这几个方面和领域，前进的步伐仍会继续，新技术、新产品、新业态的不断涌出，共同推进微服务向着更方便、更易用、低成本、高效率、高可靠、高稳定、高可运维的方向发展。
架构设计思想会继续迭代，但是这一时期构筑的软件基础框架与运载系统，将引领IT发展趋势的下一个10年。
