架构设计理念

      通常，开发团队接触一个项目时，第一反应就是撸起袖子先干起来，开一个会，定一个框架，分一下工，项目就算运转起来了。当遇到问题时，再开会再讨论，发现缺少某一个组件，赶紧上网下载一个，集成进来，再开发。项目周而复始的做，顶层设计不断的调整、优化。

      这个时候，先停下来，IT的项目应该怎么干才能事半功倍？软件设计之初就是要考虑顶层架构。

      软件方案的出发点其实是企业的战略的信息化体现。由公司的发展战略指导公司的业务发展结构，当通过对战略和业务的解析，才能整体定位出该企业的业务架构，当确认需要满足那些架构的要求时，这时候IT实现才粉末登场。

      下面这张图描述的就是战略、业务、企业级架构、IT实现的关系。

      在整个企业级架构中，分为业务架构和IT架构两部分组成。业务架构就是业务的规范流程是什么，这是一个企业管理的核心。而IT架构就是要在业务架构的指导下，对系统的实现，提出可行性的设计。IT架构中的应用架构、数据架构、技术架构是所有IT架构的顶层。下面这张图就是描述的企业架构的关系。

     业务架构描绘的是系统的整体蓝图，说明的是要做哪些事情，要在什么环境下完成。以一个简单的项目为例，按照下图的业务规划，系统要在安全和微服务的架构下，在基础平台上实现门户、项目管理、问题管理、发布管理的需求，并能实现多渠道访问。

     依照业务的指导，可以规划出功能架构，按照业务的需要将功能列举出来。通过功能评估是否符合企业的业务办理流程。

     当系统的业务架构确定后，选择的技术架构就可以考虑如何实现了，选用哪种语言，哪种组件、是否什么技术架构将在头脑风暴中列举出来，依据不同的分层再将技术路线整合到技术架构中。而程序员最喜欢的就是哪个层使用了哪些技术，而这些技术是否又是最新的、最牛的。“凯撒的归凯撒，上帝的归上帝”技术的问题就交给各位技术大牛们来规划、处理了。

      技术架构确认后，项目就要结合业务架构、网络安全策略、技术架构的要求，划分不同的业务域完成分组，确立应用架构，例子当中的就是依据前后端分离、微服务的要求，将应用分为前端应用、网管应用、注册中心、权限中心、业务中心和数据存储应用。切分应用后就可以组织出下面的应用架构图了。

     当应用架构确立后，部署架构依据应用架构的设计可以安排如何部署，需要开通哪些安全策略，部署在哪些服务器上。例子中的应用由于项目较小，分别将前端、后端、数据库分别部署在三个机器上，如果系统非常庞大时，就需要将各种的应用集群、分服务器部署了。

       当应用架构确立好后，数据架构就被提到议程上了。数据是否要结构化存储，什么需要非结构化存储，哪些需要缓存，这些依据技术架构的选型，被区分出哪些类型的数据存储在哪些数据库中。如图在mysql中存储的是业务、代码、组件的要求结构化数据。而redis中存储的就是临时的缓存、ES中存储的就是日志信息。通过其他已有的关联Oracle库的信息考虑ETL或自动任务同步数据。数据架构就是划分存储的类型。

     数据架构确立后，数据流图就是能清晰的描绘出数据的流向，数据的流能指导在网络中访问的安全策略了。

     当这些架构确立好后，系统就可以按部就班的开展开发了，当系统需求做出重大调整时，就可以在顶层设计的架构中做出整体的调整。这就能在后续的维护中保障项目的稳健推进。