一方面，系统架构的演进随着互联网的发展，网站应用的规模不断扩大。 需求的激增，带来了技术压力。 因此，系统体系结构也在不断演变、升级和迭代。 从单个APP应用程序到垂直划分、分布式服务、SOA，再到当前炙手可热的微服务体系结构，再到在谷歌引领下发展壮大的服务消息。 我们应该坐微服的船驶向远方，还是在偏安的一个角落度过？
其实生活不仅有眼前的不雅点，还有诗和远方。 所以今天我们来回顾历史，看看系统体系结构演化的历史。 学习当今最流行的技术架构； 展望未来，努力成为优秀的Java工程师。
1 .在集中式体系结构站点流量较少的情况下，在一个APP应用程序中集中部署所有功能，以降低部署节点和成本。 此时，用于简化追加删除重新评估工作量的数据访问框架(ORM )是影响项目开发的关键。
如图所示，该系统采用了三层架构、表示层、业务逻辑层、数据访问层，而三层架构解决了APP应用中代码间调用复杂、代码作用不明显的问题。 但是，他只是在逻辑上将APP应用程序分为三层，而不是物理层。 编译、打包和部署后，最终仍将在同一台计算机上的同一进程中运行。 这些功能的集中、代码的中心化、一个分发包和部署后在同一过程中运行的APP应用程序通常称为单体系结构APP应用程序。
单体APP应用程序有什么好处？
易于开发、易于测试、易于部署的问题：
代码耦合、开发维护困难，无法针对不同模块进行针对性优化，无法进行水平扩展，单点容错低，并发性低，技术选型成本高-单机APP应用极其需要采用新的框架和语言例如，假设有200万行使用XYZ框架的代码。 如果尝试使用ABC框架重写代码，那么时间和成本都非常高。 即使新框架更好，它也会妨碍使用新技术。 提供周期长-通常采用release train方法，在发布之前提供所需的所有功能。 2、垂直分段访问量逐渐增加，单个APP应用无法满足需求时，系统按照业务功能进行分段，以满足更高的并发需求。
好处：
系统划分实现了流量分担，解决了并发问题，解决了优化到不同模块容易扩展水平、负载均衡、容错能力提高的缺点。
系统之间相互独立，有很多重复开发工作，影响开发效率。 3、分布式服务的垂直APP应用越来越多，APP应用之间的交互不可避免。 提取核心业务，作为独立的服务，逐步形成稳定的服务中心，使前端APP应用能够更快地适应变化的市场需求。 在这种情况下，用于提高业务复用和整合的分布式调用很重要。
好处：
提取基础服务，在系统之间进行相互调用，提高了代码复用和开发效率的缺点：
系统间耦合度变高，调用关系错综复杂，维护困难。 4、服务管理SOA微服务和SOA
SOA
SOA的首次出现是提出服务重用和消息总线，以解决企业不同系统之间的集成问题。 SOA有很多组织，通常通过消息总线承载业务逻辑，构建重量级的中心化中间件。 SOA的主要问题是总线，根据这一思想，这些系统会在某个地方集中，所以中心化不彻底。 微服务
目标：帮助企业快速响应变化：添加调度中心，以根据访问压力实时管理群集容量，提高群集利用率(如果增加了去中心化服务，并且出现了容量评估、小服务资源浪费等问题) 此时，用于提高设备利用率的资源调度和管理中心(SOA )很重要
以前有什么问题吗？
服务增加，需要管理各服务的地址调用关系错综复杂，难以组织依赖关系，服务状态管理困难，无法根据服务情况动态管理服务管理
服务注册中心，实现服务的自动注册和发现，不需要人为记录服务地址服务的自动订阅，服务列表自动推送，服务呼叫透明，无需在意依赖关系，动态监控服务状态监测报告，
服务之间存在依赖关系，在某些环节出错会影响大服务关系的复杂性，运维、测试部署困难，不符合DevOps思想二、微服务前面提到的SOA。 用英语翻译是面向服务的。 微服务，也是一种服务，似乎分割了系统。 因此，两者非常容易混淆，但其实有一些区别：
1、微服务特点单一职责：微服务中每一个服务对应唯一业务能力，实现单一职责微。 微服务的服务分割粒度小，例如由一个用户管理就可以是一个服务。 虽然各项服务小，但“五脏俱全”。 面向服务：面向服务是指为每个服务向外部公开服务接口API。 不关心服务的技术实现，与平台和语言无关，只要不限定用什么技术实现，提供Rest的接口即可。 自治：自治是指服务之间相互独立，互不干扰团队独立。 各项服务是独立的开发团队，人数不能过多增加。 技术独立：面向服务，提供Rest接口，无论使用什么技术，他人都不会干扰前后端的分离。 采用前后端分离开发，提供统一的Rest接口，后端可以不再为PC、移动段开发不同的接口数据库分离。 为每个服务使用自己的数据源部署独立，以确保即使在服务之间进行调用，重新启动服务也不会影响其他服务。 有助于持续整合和持续提供。 每项服务都是独立的组件，可复用、可更换、减少耦合，易于维护微服务的结构图。
2、微服务设计原则
3、高凝聚性和低耦合性密切相关的要放在一起，各项服务是单一职责业务能力的封装，集中在一件事上(
的理由)。如下图：有四个服务a,b,c,d，但是每个服务职责不单一，a可能在做b的事情，b又在做c的事情，c又同时在做a的事情，通过重新调整，将相关的事物放在一起后，可以减少不必要的服务。轻量级的通信方式 同步RESTful（GET/PUT/POST…），基于http，能让服务间的通信变得标准化并且无状态，关于RESTful API的成熟度，可参Richardson为REST定义的成熟度模型异步（消息队列/发布订阅）避免在服务与服务之间共享数据库 4、高度自治 独立部署运行和扩展 每个服务能够独立被部署并运行在一个进程内这种运行和部署方式能够赋予系统灵活的代码组织方式和发布节奏，使得快速交付和应对变化成为可能。独立开发和演进 技术选型灵活，不受遗留系统技术栈的约束。合适的业务问题可以选择合适的技术栈，可以独立的演进服务与服务之间采取与语言无关的API进行集成独立的团队和自治 团队对服务的整个生命周期负责，工作在独立的上下文中， 谁开发，谁维护。5、以业务为中心 每个服务代表了特定的业务逻辑有明显的边界上下文围绕业务组织团队能快速的响应业务的变化隔离实现细节，让业务领域可以被重用弹性设计
设计可容错的系统 拥抱失败，为已知的错误而设计依赖的服务挂掉网络连接问题设计具有自我保护能力的系统 服务隔离服务降级限制使用资源防止级联错误6、NetfilixNetfilix 提供了一个比较好的解决方案，具体的应对措施包括：网络超时/限制请求的次数/断路器模式/提供回滚等。
Hystrix记录那些超过预设定的极限值的调用。它实现了circuit break模式，从而避免了无休止的等待无响应的服务。如果一个服务的错误率超过预设值，Hystrix将中断服务，并且在一段时间内所有对该服务的请求会立刻失效。Hystrix可以为请求失败定义一个fallback操作，例如读取缓存或者返回默认值。
7、日志与监控当产品环境出错时，需要快速的定位问题，检测可能发生的意外和故障。而日志与监控是快速定位和预防的不二选择，在微服务架构中更是至关重要。
高度可观察，我们需要对正在发生的事情有一个整体的视角。聚合你的日志，聚合你的数据，从而体贴的嚓茶遇到问题时，可以深入分析原因。当需要重现hhdpy问题，或仅仅查看你的系统在生产环境如何交互时，关联标识可以帮助你跟踪系统间的调用。监控主要包括服务可用状态、请求流量、调用链、错误计数，结构化的日志、服务依赖关系可视化等内容，以便发现问题及时修复，实时调整系统负载，必要时进行服务降级，过载保护等等，从而让系统和环境提供高效高质量的服务。
比如商业解决方案splunk，sumologic，以及开源产品ELK他们都可以用于日志的收集，聚合，展现，并提供搜索功能，基于一定条件，触发邮件警告。
Spring boot admin也可以用于服务可用性的监控， hystrix除了提供熔断器机制外，它还收集了一些请求的基本信息（比如请求响应时间，访问计算，错误统计等），并提供现成的dashboard将信息可视化。
关于性能监控和调用链追踪，考虑使用dynatrace和zipkin/Sleuth
8、自动化在微服务架构下，面临如下挑战：
分布式系统多服务，多实例手动测试，部署，发布太消耗时间反馈周期太长传统的手工运维方式必然要被淘汰，微服务的实施是有一定的先决条件：那就是自动化，当服务规模化后需要更多自动化和标准化的手段来提升效能和降低成本。
自动化测试必不可少，因为对比单块系统，确保我们大量的服务正常工作是一个更复杂的过程。调用一个统一的命令行，以相同的方式把系统部署到各个环境。考虑使用环境定义来帮助你明确不同环境间的差异，但同时保持使用统一的方式进行部署的能力。考虑创建自定义镜像来加快部署，并且拥抱全自动化创建不可变服务器的实践。自动化一切可以自动化的，降低部署和发布的难度, 比如： 在持续集成和持续交付中，自动化编译，测试，安全扫描，打包，集成测试，部署，随着服务越来越多，在发布过程中，需要进一步自动化蓝绿部署（做到老版本到新版本的平滑过渡）还可以使用pipeline as code的实践，用代码来描述你的流水线。关于部署有很多选择，可以使用虚拟机，容器docker，或者流行的无服务架构lambda（AWS Lambda 也有一些明显的局限。它并不适合被用来部署长期运行的服务，请求需要在 300 秒内完成，当然你可以通过hack的方式延迟时间)。
然后， 可以采用基础设施及代码的实践，比如亚马逊的cloudformation，还有terrform，通过代码来描述计算和网络等基础设施， 可以快速为一个全新的服务，构架它所需要的环境，保持各环境的一致性。
9、微服务的优点？1.每个微服务都很小，这样能聚焦一个指定的业务功能或业务需求。微服务架构模式给采用单体式编码方式很难实现的功能提供了模块化的解决方案，由此，单个服务很容易开发、理解和维护。
2.微服务能够被小团队单独开发，这个小团队是2到5人的开发人员组成。
3.微服务是松耦合的，是有功能意义的服务，无论是在开发阶段或部署阶段都是独立的，可以加快部署速度。UI团队可以采用AB测试，快速的部署变化。微服务架构模式使得持续化部署成为可能
4.微服务能使用不同的语言开发。
5.微服务易于被一个开发人员理解，修改和维护，这样小团队能够更关注自己的工作成果。无需通过合作才能体现价值。
6.微服务允许你利用融合最新技术。
7.微服务只是业务逻辑的代码，不会和HTML,CSS 或其他界面组件混合。
10、微服务架构的缺点？1.微服务架构可能带来过多的操作（服务拆分）
2.需要DevOps技巧。
3.可能双倍的努力。
4.分布式系统可能复杂难以管理。开发者需要在RPC或者消息传递之间选择并完成进程间通讯机制。更甚于，他们必须写代码来处理消息传递中速度过慢或者不可用等局部失效问题。当然这并不是什么难事，但相对于单体式应用中通过语言层级的方法或者进程调用，微服务下这种技术显得更复杂一些。
5.因为分布部署跟踪问题难。
6.当服务数量增加，管理复杂性增加
7.分区的数据库架构。商业交易中同时给多个业务分主体更新消息很普遍。这种交易对于单体式应用来说很容易，因为只有一个数据库。在微服务架构应用中，需要更新不同服务所使用的不同的数据库。使用分布式交易并不一定是好的选择，不仅仅是因为CAP理论，还因为今天高扩展性的NoSQL数据库和消息传递中间件并不支持这一需求。最终你不得不使用一个最终一致性的方法，从而对开发者提出了更高的要求和挑战。
三、认识RPCRPC，即 Remote Procedure Call（远程过程调用），是一个计算机通信协议。 该协议允许运行于一台计算机的程序调用另一台计算机的子程序，而程序员无需额外地为这个交互作用编程。说得通俗一点就是：A计算机提供一个服务，B计算机可以像调用本地服务那样调用A计算机的服务。
通过上面的概念，我们可以知道，实现RPC主要是做到两点：
实现远程调用其他计算机的服务 要实现远程调用，肯定是通过网络传输数据。A程序提供服务，B程序通过网络将请求参数传递给A，A本地执行后得到结果，再将结果返回给B程序。这里需要关注的有两点： 1）采用何种网络通讯协议？ 现在比较流行的RPC框架，都会采用TCP作为底层传输协议2）数据传输的格式怎样？ 两个程序进行通讯，必须约定好数据传输格式。就好比两个人聊天，要用同一种语言，否则无法沟通。所以，我们必须定义好请求和响应的格式。另外，数据在网路中传输需要进行序列化，所以还需要约定统一的序列化的方式。像调用本地服务一样调用远程服务 如果仅仅是远程调用，还不算是RPC，因为RPC强调的是过程调用，调用的过程对用户而言是应该是透明的，用户不应该关心调用的细节，可以像调用本地服务一样调用远程服务。所以RPC一定要对调用的过程进行封装。RPC调用流程图：
上一篇：【Spring Cloud 4】构建高性能的大型分布式网站
下一篇： SpringCloud学习总纲