架构思考

1、知识的混沌到有序

架构对于很多开发来讲，具有很大的魔性，代表着开发人员的层次，架构师的职位还是非常诱惑人。但什么是架构呢？我自己经过了很长的时间去理解它，中间有迷茫、有困惑，之前在阿里，里面有很多大牛，去请教专家，每个人对架构有自己的理解。自己也买了一些书，看到各种资料上讲的，各不尽同。那时候，知识是混沌。混沌的结果是让人无法抓到问题的本质。人的认识不尽相同，有不同的表达方式，但在本质上是相同的。

我很相信"量变"到"质变"的进化。我买了不少10本关于架构的书，起初对书中的理解没有达到一定的层次，现在回过头来看，一本好的书能让节省很多时间，这个过程也挺好的，从青涩到有一定的收获，成长的历程还是有的。写下这篇文章，希望对大家有一点帮助。

知识一定要内化成为自己的东西，所以前面提到很多专家讲的观点不一样，但在本质上对架构的理解是相同。内化为自己的东西一定是简洁、直达本质的，这个时候再回过头去看，知识是有序的，形成了一个体系，逻辑性非常强，也即常说的方法论。

2、架构理解

关于架构，刚开始我没有区分业务架构、技术架构、系统架构、部署架构，这几种不同的架构，其实相差是很大的，关注点也不相同。大部分人说着的是业务架构或者技术架构，也有系统架构。业务架构是从用户视角看整个业务的大体情况，它存在一定的扭转、流动性，要在业务架构图体现出来，同时要表明业务的场景、产品功能、依赖服务。技术架构要通过怎样的技术解决什么样的问题。系统架构是体现系统之间的关联关系。

架构，又称系统架构，系统具有什么的特性呢。是在看一本书后，对它的所讲的比较认可。系统是具有层次特性，这和我们的认识是相同的，每次看到一些东西，每次可以往下深入。其实到这里了，基本上架构的方法论就出来了，如何找到这个层次结构，架构的产出就是架构设计图(也有文字，但图更能直观表达)。

从系统的层次特性出发，总结分层的方法：拆分、抽象、合并。业务有流程，把这个流程不断拆分成小的流程，直到不能拆分，把关键的操作、功能、特性写出来，画在图上，有总的业务图，也有拆分的子流程业务图，一目了然。接下来是抽象的过程，抽象是抽出来要像，抓住本质，对子流程中的内容进行抽象，抽象的过程就是归纳，不断向上归纳总结。合并是把抽象出来的内容，按照层次特性进行排列，这样就形成了一个整体业务架构图。

3、架构感想

看书是学习认识的过程，真正还是要落实到实践的过程，这是我来滴滴最大的感想。对一个券系统进行架构后，有老大帮你指出哪些不足，应该往些地方思考。到这个时候，之前的所思、所想，到现在的实践过程，达到了合一的效果。

最后聊一下的感想：

• 坚持是一种优秀的习惯。技术有快餐技术和慢技术，快餐技术是大家一学就会，但没有竞争力；慢技术是靠沉淀，没有那么快速成的，可能需要一年，甚至几年才能悟出来的。这个过程就需要去坚持，在遇到困难时不要放弃。
• 开放接纳、总结。技术要保持开放接纳的心态，听不同的人去讲它，每个人有自己的理解和想法，没有对与错之分，只是你能不能get到别人所讲的内涵，今天我再去想当初那些专家给我讲，觉得还是对的，关键的关键是自己要总结一套自己的理解，别人讲得再好，也是别人的。要内化自己的东西，一讲出来，就与众不同，形成了一套体系，架构要怎么做，反过来要怎么去学，要看哪些书，这样初学者有指南，不会盲目去看一些书，陷入混沌状态。
• 实践出真知。想与做是两会事，做一件事会发现还是会遇到一些困难的，这个时候靠平时的实践，反过来会加深之前的理解，知识也是不断的修正，让技术体系不断圆熟于一断。

希望自己的一点心得有助于大家，个人微信号手机：13512717641，欢迎加入交流。