最近在接受一个培训,第一次接触了架构设计的知识,有些名词晦涩难懂,导致在这一块的学习还是有所欠缺。
尽管如此,在培训中和培训后的努力学习后,做了点整理,理解的可能有所偏差,欢迎拍砖。

架构设计对于一个项目来说十分重要。

一份完整的架构设计应该包括哪些内容

1）建模，提炼资源
2）系统结构（BFF，业务流程）
3）开发团队结构
4）可用性与性能架构
5）安全性架构
6）质量架构
7）部署架构
8）运维架构
9）技术选型

面向行为的接口设计与面向资源的接口设计(ROA)

面向行为的接口设计是建立在动词（行为）的基础之上的，系统要枚举所有的业务行为，如果行为发生改变，接口也随之改变。
面向资源的接口设计便于实施、设计灵活、是轻量级的对象访问方式。
面向资源的接口设计关注的是名词（资源），解决了在业务需求发生变化时要对代码做很大的改变的问题。

SOA 面向服务的架构设计

将紧耦合的系统,划分为面向业务的,粗粒度,松耦合,无状态的服务。
目的是提高软件的重用性，减少开发和维护的成本，最终增加敏捷度。

微服务架构

微服务架构其中的一个重点是业务系统需要彻底的组件化和服务化,原来的业务可以拆分成独立的系统应用进行开发,这些相互独立的系统应用通过服务完成交互和集成。
它的目的是有效的拆分应用,实现敏捷开发和部署,为构建应用提供更轻量级、更高效的开发。

微服务不再强调传统SOA架构里面比较重的ESB企业服务总线，同时SOA的思想进入到单个业务系统内部实现真正的组件化。

微服务足够构成一个独立的小应用(从DB到UI)

微服务的基本思想在于考虑围绕着业务领域组件来创建应用,这些应用可以独立的进行开发管理和加速。在分散的组件中使用微服务云架构和平台使部署管理和服务功能交付变得更加简单。

(Devops:开发测试和部署运维一体化。)

把单体应用拆分成多个小应用后,整体架构可以松耦合和可扩展,但是当拆分的组件越多,这些组件之间本省的集成和部署运维就越复杂。
任何一个组件,当依赖的外部应用组件越多的时候,整个集成,部署和连调测试的过程就越复杂,所以自动化这个过程可以减少工作量和出错概率。

微服务架构首先要做好单个组件本身的持续集成,其次在这个基础上增加了多个组件的打包部署和组件间的集成。包括环境变量的配置,自动打包部署,自动化的测试等。

不像传统多个服务共享一个数据库,微服务架构每个服务都有自己的数据库。

一般运行在云虚拟机或者更轻的Docker上

微服务架构强调了单个组件本身可以在独立的进程里面运行,各个组件之间在部署的时候就能够做到进程级别的隔离性。
为了保持进程的隔离性,使用虚拟机,但是几十个进程都完全用独立的虚拟机就不现实,解决方案为利用Docker容器,每个Docker是独立的容器,完全做到了进程季节的隔离,资源占用率最小,满足了微服务架构的开发测试和自动化部署。

微服务应用之间只能通过Service API进行交互

单个服务的实现和发布仍然在组件内部完成,但是需要一个统一的SOA服务管理平台来显示服务本身的调用情况,服务本身的安全,日志和流量控制。
微服务强调采用HTTP Rest API的方式。
即微服务尽量通过HTTP API的方式暴露出去,因此这种服务管理平台需要基本的服务注册,服务代理,服务发布,服务简单的路由,安全访问和授权,服务调用消息和日志记录功能。

微服务架构的优势

1.通过分解巨大单体式应用为多个服务方法解决了复杂性问题。在功能不变的情况下,应用被分解为多个可管理的分支或服务。单个服务很容易开发、理解和维护。
2.每个服务都可以有专门的开发团队并行开发。
3.每个服务独立部署,不需要协调其他服务部署对本服务的影响,加快了部署速度,使得持续化部署成为可能。
4.每个服务可独立扩展。
5.每个服务足够内聚，足够小，代码容易理解、开发效率提高。
7.提高容错性，一个服务的内存泄露并不会让整个系统瘫痪。
8.可以使用多个技术栈,系统不会被技术栈长期限制。

微服务架构的不足

1.一个应用系统里面的模块没有办法做到彻底解耦,无法实现组件单独部署,相互之间有大量内部不可见依赖而导致了模块间的无法拆分。
2.微服务应用式分布式系统,会带来固有的复杂性。
3.分区的数据库架构带来的挑战,因为需要更新不同服务所使用的不同的数据库。
4.测试一个基于微服务架构的应用很复杂。
5.微服务架构模式应用的改变将会波及多个服务。
6.部署一个微服务应用也很复杂，一个分布式应用只需要简单在复杂均衡器后面部署各自的服务器就好了。每个应用实例是需要配置诸如数据库和消息中间件等基础服务。

微服务的特征:

通过服务实现组件化
按业务能力来划分服务于组织团队
服务即产品
智能终端与哑管道
去中心统一化
基础设施自动化
Design for failure
进化设计

微服务总结

一个微服务一般完成某个特定的功能,每个微服务都是一个微型应用,有着自己的六边形架构,包括商业逻辑和各种接口。
有的微服务通过暴露API被别的微服务或者应用客户端所用;有的微服务则通过UI实现。在运行时,每个实力通常时一个云虚拟机或者Docker容器。

SOA、微服务、服务化这几个概念的差别和关系

SOA服务导向架构，将应用程序功能作为服务发送给最终用户或者其他服务，是整合各种业务的应用程序。
微服务是一种以业务功能为主的服务设计，通过将功能分散到各个离散的服务中以实现对解决方案的解耦，所以每一个服务都具有自主运行的业务功能。微服务只属于一个应用程序，它要求业务系统彻底的组件化和服务化。
服务化是一种粗粒度、松耦合的以服务为中心的架构，服务之间通过定义明确的协议和接口进行通信。

好的架构应该具备的特征

基于资源的接口设计
开发团队结构要正确映射系统架构
要考虑业务架构和组织架构

参考文章:
软件架构模式
SOA和微服务的区别
微服务架构的优势与不足
解析微服务架构(一)
基于微服务的软件架构模式
组件化、模块化、集中式、分布式、服务化、面向服务的架构、微服务架构