认识达内从这里开始

软件编程开发技术都是不断的在更新换代的，而本文我们就通过案例分析来简单了解一下，软件开发架构常用技术分享。

1、微服务时代

微服务的九个核心业务与技术特征

围绕业务能力构建：根据业务划分细粒度的服务和团队;

分散治理：各服务、各团队对服务质量各自负责，不受其他服务影响，可以各自演进而不用统一规化;

通过服务而不是类库来实现自治;

产品化思维：各服务开发人员关注整个微服务的全方位生命周期，大家不是为了仅仅完成某个功能，而是提供一个持续改进、提升的服务;

数据去中心化：允许不同的存储方式或者存储位置，但要考虑分布式一致性的成本;

强终端弱管道：即弱化类似SOAP的通信机制(通信管道设计很重，所有服务强制依赖，多了很多不必要的管道功能)，如果有调用需要，提供服务终端的endpoint去调用而不是强制管道使用;

容错性设计：认为各服务是可以出错的，并不会直接影响所有服务的运行;

演进式设计：不仅可以容错，也可以允许某个服务突然被淘汰;

基础设置自动化：通过CI/CD等自动化构建、发布、运维，减少人工维护成本。

微服务相比SOA的优势

微服务不是SOA的变体或者衍生品，微服务中的每一部分可以自由的选择其中的各种可选方案，例如远程调用有RMI、Dubbo、Rest;服务发现有ZK、Etcd等。也因为选择很多，对于架构师而言是一个很沉重的挑战。

2、云原生时代

用硬件方案替代软件方案

对于注册、跟踪治理、均衡等问题，能否脱离应用代码实现，直接在硬件层面来实现?很早以前行不通，因为硬件基础设置跟不上软件应用的灵活性。直到docker和k8s的出现。微服务时代离不开以docker为代表的早期容器化技术，微服务框架springCloud所支持的软件级别微服务治理功能，都能够在k8s中找到硬件层面的替代：

通过k8s和相关的虚拟化技术，与业务无关的技术性问题可以从软件层面剥离，直接在硬件设置层面进行解决!

二次进化

当涉及调用链路的切换或者变更，单纯依靠DNS的硬件层面来做切换还是比较困难的，不如软件方案灵活。于是引入了“服务网格”的边车代理模式，类似于脱离应用代码，在容器中部署一个通信代理服务器，对于请求的熔断、变更、流量控制都可通过这个代理服务器来管控。这样微服务应用代码中无需再考虑任何和上面这些通信过程相关的逻辑了，全部通过三方的代理服务器实现!

3、无服务(ServerLess)时代

无服务的定义

后端即服务：数据库、存储、日志等业务无关的后端等都存储在云上;

函数即服务：供使用者调用的函数/接口都是运行在云端，调用者不需要考虑容量规划和算力问题。

无服务的愿景

开发者只需要纯粹地关注业务;

不需要考虑技术组件，后端组件现成的，直接使用，不用考虑如何采购和选型;

不用操心运维，运维能力交给云计算厂商。

无服务的缺点

对于信息管理系统、网络游戏或者对后端接口响应速度较高的应用而言，无服务并不是佳选择，因为无服务的函数肯定不会一直处理高活跃度状态，存在冷启动的情况，对于其响应性能会有影响。

【免责声明】本文系本网编辑部分转载，转载目的在于传递更多信息，并不代表本网赞同其观点和对其真实性负责。如涉及作品内容、版权和其它问题，请在30日内与管理员联系，我们会予以更改或删除相关文章，以保证您的权益!请读者仅作参考。更多内容请加抖音太原达内IT培训学习了解。