临沂白癜风医院 https://m-mip.39.net/nk/mipso_5779771.html“
首先，这篇文章肯定会得罪一些人
“
其次，此文只代表我个人的意见，仅供参考
从分层说起
谈到系统架构的分层和系统领域边界的划分，每个架构师，每个技术经理，甚至每个程序员都有自己的一套想法。无论是怎么样的划分方案，总体的目标始终是一致的，打造一个高性能，高可用，高可扩展，高安全性的系统，甚至会附加上一大堆的专业名词，例如：高度一致性，可重用性，幂等性，兼容性等等。对于最终用户来说，无论系统怎么样架构设计，稳定性是第一位的。假如系统三天两头打不开，报服务器错误，程序员岂不是天天要被祭天？
从很久之前的面向过程编程模式，到现在的面向对象设计，微服务架构方案，都体现着架构设计一直在追求更加极致的设计之美。而这种美要归功于系统的分层设计，小到类的职责划分，大到系统的分布式部署。
系统为什么一定要做分层呢？至于系统领域的划分，本质上也是一种分层设计的体现思想。
分层是软件工程中一种常见的设计方式，它根据整个系统的职责链把系统逻辑上拆分为多个层，每个层都有相对明确的独立的职责，多个层通过协调提供完整的功能。至于每层负责什么职责，软件工程学并没有明确的定义，系统的设计者可以根据系统特点来具体划分，比如：最常见的三层架构设计，把整个系统划分为：
UI层，主要负责用户UI的职责业务层，主要负责业务逻辑相关职责数据持久化层，主要负责数据的持久化，落盘操作image
还有我们耳熟能详的OSI网络模型，它把整个网络划分为了七层，每层都有相对明确的职责，但是还有另外一种划分方式把网络模型划分为四层，这是根据不同职责来划分网络的典型案例。
软件设计采用分层设计算是一种工程学，它把整体系统划分为不同的层，之后采用不同的依赖方式来组织功能，带来了很多优势
每层的职责明确，而且依赖关系明确每层都可以复用，减少了代码重复率每层都可以相对独立的做修改，扩展等，不会影响其他层
看到不少技术经理乃至架构师一直鄙视使用三层架构的程序员，我觉得你需要反思一下。最简单的三层架构模式并非优势全无，据我所知，在快速应对中小系统开发的时候，三层架构仍然是首选。不要整天拿着所谓的DDD说事，DDD也不是银弹，简单的三层架构，甚至贫血模型开发模式也有自己的优势，更何况一些人高举DDD的“聚合根”，“值类型”等概念，其实并未真正理解其含义和设计理念，自以为看了几篇DDD的文章，就可以妄自吹嘘自己精通DDD，领域模型开发确实是好的开发理念，但是它也有自己的劣势，不是任何系统用DDD开发都是最优的，更何况那些没有实际DDD开发经验的“高层”。
系统拆分
虽然分层设计优势很明显，但是随着系统业务越来越复杂，就面临着层次划分越来越多的窘态。这也是系统发展的一个必然结果，也是单体应用的必然瓶颈。所以系统按照业务拆分是业务发展到一定阶段的结果，而并非架构师主观意愿的结果。随着子系统越来越多，部署和运维工作也随着越来越多，所以自动化的部署需求也随之出现，为了更好的实现每个系统的可扩展性，稳定性，可用性等软性需求，kubernetes也越来越受到追捧。
其实系统拆分是一个很泛的概念，业界并没有实际的拆分原则，只是大部分人喜欢以业务为维度来进行拆分，实际证明按照业务拆分也是正确的。被拆分的不止是业务逻辑的代码，包括业务的数据库等也会被彻底物理隔离，因为只有这样才可以做到真正的高内聚，低耦合。
image架构设计
当每个服务都可以根据自身业务量来进行横向扩展或者纵向扩展的时候，就可以体现出微服务的优势。而具体的系统架构设计决定着这个服务是否可以灵活的应对多变的业务需求，说到底，我们又回到怎样设计单体系统的话题上来了。其实设计好单体架构并不比分布式系统容易，一个好的单体系统同样也需要设计模式，数据结构，算法和抽象。前面所说的三层架构是其中一种选择。
系统的设计离不开业务，任何脱离业务的系统架构设计都是耍流氓。设计一个灵活的系统需要对业务的变化点进行正确的识别，然后进行抽象，比如：注册新用户的时候，需要给用户发送短信欢迎语，其实这是一个业务的变化点，因为产品不知道哪天会有一个发送邮件的欢迎语，甚至如果
