架构思维的4代迭代变更

架构思维的4代迭代变更

——技术中台

• 前提

技术架构不是越简单越好，也不是考虑越周全越好；技术需要考虑业务发展阶段、产品所处形态，兼顾强内聚弱耦合。

                                          

商业模式决定产品形态、产品形态决定技术架构

• 业务形态分析

 

图1.0—业务形态更替

目前各个行业的业务软件不管是管理类型的软件，还是电商类型，又或者是媒体内容等新型电商系统，从业务形态看基本都是侧重切入某1-N点，目标基本都是以其核心服务能力加上整合资源能力，形成行业垂直或者领域横向的业务平台，因此就行业形态分析其规划发展轨迹：

1. 初创单一业务服务切入：

这个时期的特点，要求快速，基本很难顾及到研发资源的配比、质量、架构合理等等问题。

1. 中期多端多点服务：

业务开始推广之后，业务层面会接入多方的业务服务寻求快速发展，这个时期很难顾及到规划的合理性做到有的放矢。

1. 后期SAAS混合云平台：

处于成熟期的平台服务具备多元化服务能力、服务&资金&规划互补能力、孵化再发展能力，平台满足私有云+公有云混合部署的模式，满足企业个性安全需求兼顾全网协同互通的要求。

• 技术架构变革

技术架构随着业务场景使用的变化，由单体服务（chimney）、模块化服务（MVC）、集群服务（SOA）发展到微服务（MSA）经历4代设计思维的变迁。每一种设计思维处理一类对应的业务发展问题，因此没有绝对的优秀或者低能之分，只有是否符合业务现状及发展之别。

1. 烟囱思维--单体服务（chimney- Single service）

 

                                                              

                                                                           图2.0—烟囱服务

         单体运用服务是第一代软件架构设计思维，通俗的说法就是把所有的逻辑写到一个服务中、甚至是写到一个文档中（比如2000年左右的JSP+Servlet技术,几乎可以一个文档写完所有的逻辑、数据、展示），所以使用一条路走到头的“烟囱思维”来概括。

1. 优点：一个字“快”，研发部署发布均很快。
2. 缺点：

1. 数据、业务逻辑、展示全部都写死在一起，高耦合度；
2. 扩展难、维护难、变更难，变一发则动全身；
3. 无法应对高并发、无法集群；
4. 无法容错，无法热备；
5. 代码臃肿高度依赖原作者；
6. 无法形成规范。

1. 分层思维—模块化服务（MVC- Model View Controller）

 

                            

                                                                                     图3.0—分层服务

          分层的设计架构思维，旨在解决单体应用内部解耦问题，将原来混沌未开的杂糅体按照其作用功能划分为展示给用户的视图层（V-view）、控制业务逻辑的控制层（C- controller）、定义对象模型属性的数据模型层（M-Model），分层逐层调用，不建议同层调用。

1. 优点：

1. 应用代码内部解耦，便于维护修改；
2. 根据相同作用模块强内聚，便于功能扩展增量开发；
3. 分层逐层调用模式便于功能代码复用；
4. 针对每层的特点慢慢开始形成规范。

1. 缺点：

1. 虽然分层、但是并不能存在多个相同层的相同服务，依旧没办法实在热备，难逃单体应用的命运；
2. 无法实现集群；
3. 无法容错，功能一个异常则坏全部；
4. 承载用户数有限，受制于控制层的统一服务能力，成为咽喉瓶颈，一般单体应用并发很难超过1000/秒。

1. 分布式思维--集群服务（SOA- Service oriented architecture）

 

                                                      

                                                                              图4.0—分布式服务

         在MVC发展的同时，系统应用场景很快达到了上述的咽喉瓶颈，2008年出现红极一时的分布式架构思维，同时提出了面向服务的设计原则。大家耳熟能详的session共享、会话容器同步、LBS负载均衡、热备等等技术为从网络架构层面解决业务系统的并发问题提供了很好的支持。

1. 优点：

1. 支持集群、热备；
2. SOA理念的引入及ESB总线技术的出现，进一步拆解单体应用服务，更多的按照服务内容构建单体应用，更加便于扩展、维护；
3. 支持异构系统的集成，为强技术栈依赖解绑，只要遵守相同的协议即可；
4. 提供最初的服务监控，但是无法实现服务治理。

1. 缺点：

1. 属于重量级框架、一般的技术团队均无法使用，门槛高、应用难度大；
2. ESB总线技术是基于网络的异构系统解决方案，通讯为soap\webservice等协议，信息格式以XML为主，网络通讯压力大；
3. 主业务逻辑和服务更多的还是以单体应用的形式存在集群的网络环境中；网络架构解决业务问题的实践方式，泛集群；
4. 网络技术驱动架构设计的方式，远离现实和业务；
5. 开发、测试、生成环境分离，带来环境性问题。

1. 业务具实化思维—-微服务（Micro service）

                         

                                                                            图5.0—微服务体系

到2015年底在SOA的基础上，提出了微服务概念，旨在通过领域驱动技术架构，让架构回归业务及生活本身，同时在网络集群架构的基础上应用业务集群能力处理并发，真正识别出那些需要集群的业务，不再进行泛化的集群方式处理并发问题，是到目前位置最为优秀的“面向服务”解决方案。

1. 优点：

1. 分而治之，单个服务功能内聚，复杂性低；方便团队的拆分和管理；
2. 可伸缩，能够单独的对指定的服务进行伸缩；
3. 迭代周期短，支持快速的迭代开发；
4. 唯一的一种独立测试、独立部署、独立运行的软件架构模式；
5. 研发、测试、生成环境一体化；
6. 短路型的容错机制。

1. 缺点：

1. 可维护性差，应用流程常常垮多个微服务，不易进行问题的定位；
2. 效率相对低，团队依赖强，一个服务的版本延迟会拖慢整个应用的开发周期；
3. 开发难度大，垮服务的调用通常是不同的机器，甚至是不同的机房，开发人员需要处理超时、网络异常等问题；

• 平台架构设计

目前公司的各个模块（ERP、业务编辑器、项目管理系统、营销系统、行业应用模块）基于历史原因使用了非统一的技术体系，带来了系统孤岛的尴尬，也无法从技术战略层面支持公司的业务、发展。

                      

 

                                                                         图6.0—技术平台架构

 

作为公司级的技术平台，需要具备支持公司业务发展的基础条件，分离平台基础服务、业务功能服务：

1. 平台基础服务

1. 统一认证：公司平台只有一个登录中心，该中心只是负责认证，不保存用户的账户和密码；
2. 统一权限：所有服务均将功能服务上报到统一权限的功能管理模块，由权限系统管理；并提供配置永久权限、临时一次性授权及时段授权服务模式；
3. 高可用服务注册发现：统一的服务注册发现中心，提供热插拔模式的服务注册；
4. 统一服务配置 ：统一进行所有服务的参数配置服务；
5. 服务监控：监控所有服务的运行使用实时状态；
6. 日志服务：统一监管所有服务的实时运行日志；
7. 缓存服务：集成redis+ MongoDB以key-Value模式缓存用户、服务经常使用的静态值，搭建高可用的缓存服务集群；
8. 异常服务：统一的平台异常定义服务，统一管理所有服务的异常定义和返回；
9. 文件服务：提供统一的平台级的静态文件上传、下载、预览服务；
10. 短信服务：提供统一的短信发送、收取服务，需要使用集成第三方的短信通道，根据需要有广告短信和验证短信两类；
11. 邮件服务：提供统一的邮件收发服务；
12. 数据中心：提供统一的数据中心，搭建数据库集群，按照服务需要创建不同的实列；