K8s已经成为一线大厂分布式平台的标配技术。你是不是还在惆怅怎么掌握它？来这里，大型互联网公司一线工程师亲授，不来虚的，直接上手实战，3天时间带你搭建K8s平台，快速学会K8s，点击下方图片可了解培训详情，点击下方图片了解详情。
-
开发简单直接，集中式管理，基本不会重复开发
-
开发效率低：所有的开发在一个项目改代码，递交代码相互等待，代码冲突不断
-
代码维护难：代码功能耦合在一起，新人不知道何从下手
-
部署不灵活：构建时间长，任何小修改必须重新构建整个项目，这个过程往往很长
-
稳定性不高：一个微不足道的小问题，可以导致整个应用挂掉
-
扩展性不够：无法满足高并发情况下的业务需求
-
一组小的服务，服务粒度要小，而每个服务是针对一个单一职责的业务能力的封装，专注做好一件事情。
-
独立部署运行和扩展，每个服务能够独立被部署并运行在一个进程内。这种运行和部署方式能够赋予系统灵活的代码组织方式和发布节奏，使得快速交付和应对变化成为可能。
-
独立开发和演化，技术选型灵活，不受遗留系统技术约束。合适的业务问题选择合适的技术可以独立演化。服务与服务之间采取与语言无关的API进行集成。相对单体架构，微服务架构是更面向业务创新的一种架构模式。
-
独立团队和自治，团队对服务的整个生命周期负责，工作在独立的上下文中，自己决策自己治理，而不需要统一的指挥中心。团队和团队之间通过松散的社区部落进行衔接。
-
Autonomous，A Microservice is a unit of functionality; it provides an API for a set of capabilities oriented around a business domain or common utility
-
Isolated，A Microservice is a unit of deployment; it can be modified, tested and deployed as a unit without impacting other areas of a solution
-
Elastic，A Microservice is stateless; it can be horizontally scaled up and down as needed
-
Resilient，A Microservice is designed for failure; it is fault tolerant and highly available
-
Responsive，A Microservice responds to requests in a reasonable amount of time
-
Intelligent，The intelligence in a system is found in the Microservice endpoints not ‘on the wire’
-
Message Oriented，Microservices rely on HTTP or a lightweight message bus to establish a boundary between components; this ensures loose coupling, isolation, location transparency, and provides the means to delegate errors as messages
-
Programmable，Microservices provide API’s for access by developers and administrators
-
Composable，Applications are composed from multiple Microservices
-
Automated，The lifecycle of a Microservice is managed through automation that includes development, build, test, staging, production and distribution
-
每个微服务都很小，这样能聚焦一个指定的业务功能或业务需求。
-
微服务能够被小团队单独开发，这个小团队是2到5人的开发人员组成。
-
微服务是松耦合的，是有功能意义的服务，无论是在开发阶段或部署阶段都是独立的。
-
微服务能使用不同的语言开发。
-
微服务允许容易且灵活的方式集成自动部署，通过持续集成工具，如Jenkins，bamboo。
-
一个团队的新成员能够更快投入生产。
-
微服务易于被一个开发人员理解，修改和维护，这样小团队能够更关注自己的工作成果。无需通过合作才能体现价值。
-
微服务允许你利用融合最新技术。
-
微服务只是业务逻辑的代码，不会和HTML，CSS 或其他界面组件混合。
微服务能够即时被要求扩展。
-
微服务能部署中低端配置的服务器上。
-
易于和第三方集成。
-
每个微服务都有自己的存储能力，可以有自己的数据库。也可以有统一数据库。
-
微服务架构可能带来过多的操作。
-
需要DevOps技巧
-
可能双倍的努力。
-
分布式系统可能复杂难以管理。
-
因为分布部署跟踪问题难。
-
当服务数量增加，管理复杂性增加。
-
单个微服务代码量小，易修改和维护。但是，系统复杂度的总量是不变的，每个服务代码少了，但服务的个数肯定就多了。就跟拼图游戏一样，切的越碎，越难拼出整幅图。一个系统被拆分成零碎的微服务，最后要集成为一个完整的系统，其复杂度肯定比大块的功能集成要高很多。
-
单个微服务数据独立，可独立部署和运行。虽然微服务本身是可以独立部署和运行的，但仍然避免不了业务上的你来我往，这就涉及到要对外通信，当微服务的数量达到一定量级的时候，如何提供一个高效的集群通信机制成为一个问题。
-
单个微服务拥有自己的进程，进程本身就可以动态的启停，为无缝升级的打好了基础，但谁来启动和停止进程，什么时机，选择在哪台设备上做这件事情才是无缝升级的关键。这个能力并不是微服务本身提供的，而是需要背后强大的版本管理和部署能力。
-
多个相同的微服务可以做负载均衡，提高性能和可靠性。正是因为相同微服务可以有多个不同实例，让服务按需动态伸缩成为可能，在高峰期可以启动更多的相同的微服务实例为更多用户服务，以此提高响应速度。同时这种机制也提供了高可靠性，在某个微服务故障后，其他相同的微服务可以接替其工作，对外表现为某个设备故障后业务不中断。同样的道理，微服务本身是不会去关心系统负载的，那么什么时候应该启动更多的微服务，多个微服务的流量应该如何调度和分发，这背后也有一套复杂的负载监控和均衡的系统在起作用。
-
微服务可以独立部署和对外提供服务，微服务的业务上线和下线是动态的，当一个新的微服务上线时，用户是如何访问到这种新的服务？这就需要有一个统一的入口，新的服务可以动态的注册到这个入口上，用户每次访问时可以从这个入口拿到系统所有服务的访问地址。这个统一的系统入口并不是微服务本身的一部分，所以这种能力需要系统单独提供。
-
还有一些企业级关注的系统问题，比如，安全策略如何集中管理？系统故障如何快速审计和跟踪到具体服务？整个系统状态如何监控？服务之间的依赖关系如何管理？等等这些问题都不是单个微服务考虑的范畴，而需要有一个系统性的考虑和设计，让每个微服务都能够按照系统性的要求和约束提供对应的安全性，可靠性，可维护性的能力。
-
服务价值的精华体现
-
可靠、可用、可读
-
只有一次机会
-
Version
-
RequstID
-
Auth&Signature
-
RateLimit
-
Docs
-
ErrorCode&Message
-
按需伸缩，部署与监控运维成本
-
独立部署，机器数量与部署成本
-
业务独立，服务依赖、治理，版本管理、事务处理
-
技术多样性，环境部署成本、约定成本
-
运行状态治理，监控、限流、SLA、LB、日志分析
-
服务注册与发现
-
部署
-
快速、复制、扩容
-
单机开发
-
调用，安全、容错、服务降级、调用延时
-
服务注册、发现、负载均衡和健康检查，假定采用进程内LB方案，那么服务自注册一般统一做在服务器端框架中，健康检查逻辑由具体业务服务定制，框架层提供调用健康检查逻辑的机制，服务发现和负载均衡则集成在服务客户端框架中。
-
监控日志，框架一方面要记录重要的框架层日志、metrics和调用链数据，还要将日志、metrics等接口暴露出来，让业务层能根据需要记录业务日志数据。在运行环境中，所有日志数据一般集中落地到企业后台日志系统，做进一步分析和处理。
-
REST/RPC和序列化，框架层要支持将业务逻辑以HTTP/REST或者RPC方式暴露出来，HTTP/REST是当前主流API暴露方式，在性能要求高的场合则可采用Binary/RPC方式。针对当前多样化的设备类型（浏览器、普通PC、无线设备等），框架层要支持可定制的序列化机制，例如，对浏览器，框架支持输出Ajax友好的JSON消息格式，而对无线设备上的Native App，框架支持输出性能高的Binary消息格式。
-
配置，除了支持普通配置文件方式的配置，框架层还可集成动态运行时配置，能够在运行时针对不同环境动态调整服务的参数和配置。
-
限流和容错，框架集成限流容错组件，能够在运行时自动限流和容错，保护服务，如果进一步和动态配置相结合，还可以实现动态限流和熔断。
-
管理接口，框架集成管理接口，一方面可以在线查看框架和服务内部状态，同时还可以动态调整内部状态，对调试、监控和管理能提供快速反馈。Spring Boot微框架的Actuator模块就是一个强大的管理接口。
-
统一错误处理，对于框架层和服务的内部异常，如果框架层能够统一处理并记录日志，对服务监控和快速问题定位有很大帮助。
-
安全，安全和访问控制逻辑可以在框架层统一进行封装，可做成插件形式，具体业务服务根据需要加载相关安全插件。
-
文档自动生成，文档的书写和同步一直是一个痛点，框架层如果能支持文档的自动生成和同步，会给使用API的开发和测试人员带来极大便利。Swagger是一种流行Restful API的文档方案。
-
日志和审计，主要是日志的汇总，分类和查询
-
监控和告警，主要是监控每个服务的状态，必要时产生告警
-
消息总线，轻量级的MQ或HTTP
-
注册发现
-
负载均衡
-
部署和升级
-
事件调度机制
-
资源管理，如：底层的虚拟机，物理机和网络管理
-
认证和鉴权
-
微服务统一代码框架，支持多种编程语言
-
统一服务构建和打包
-
统一服务测试
-
微服务CI/CD流水线
-
服务依赖关系管理
-
统一问题跟踪调试框架，俗称调用链
-
灰度发布
-
蓝绿部署
-
容器够小，解决微服务对机器数量的诉求
-
容器独立，解决多语言问题
-
开发环境与生产环境相同，单机开发、提升效率
-
容器效率高，省钱
-
代码/image一体化，可复用管理系统
-
容器的横向与纵向扩容
-
可复制
-
可动态调节CPU与内存
-
Image管理
-
系统安全管理
-
授权管理
-
系统成熟度
-
社区成熟度
-
首先需要考虑构建DevOps能力，这是保证微服务架构在持续交付和应对复杂运维问题的动力之源；
-
其次保持服务持续演进，使之能够快速、低成本地被拆分和合并，以快速响应业务的变化；
-
同时要保持团队和架构对齐。微服务貌似是技术层面的变革，但它对团队结构和组织文化有很强的要求和影响。识别和构建匹配架构的团队是解决问题的另一大支柱。
-
最后，打造持续改进的自组织文化是实施微服务的关键基石。只有持续改进，持续学习和反馈，持续打造这样一个文化氛围和团队，微服务架构才能持续发展下去，保持新鲜的生命力，从而实现我们的初衷。
- 左青龙
- 微信扫一扫
-
- 右白虎
- 微信扫一扫
-
评论