基于html5动画的网站,合肥建设网站,山东建站管理系统,做网站 页面自适应微服务 软件架构是一个包含各种组织的系统组织#xff0c;这些组件包括 Web服务器, 应用服务器, 数据库,存储, 通讯层), 它们彼此或和环境存在关系。系统架构的目标是解决利益相关者的关注点。 image Conway’s law: Organizations which design systems[...] are constrained…微服务 软件架构是一个包含各种组织的系统组织这些组件包括 Web服务器, 应用服务器, 数据库,存储, 通讯层), 它们彼此或和环境存在关系。系统架构的目标是解决利益相关者的关注点。 image Conway’s law: Organizations which design systems[...] are constrained to produce designs which are copies of the communication structures of these organizations. 设计系统的组织其产生的设计和架构等价于组织间的沟通结构。) Monolithic架构
2016102722 Monolithic比较适合小项目优点是 开发简单直接集中式管理, 基本不会重复开发 功能都在本地没有分布式的管理开销和调用开销。它的缺点也非常明显特别对于互联网公司来说不一一列举了 开发效率低所有的开发在一个项目改代码递交代码相互等待代码冲突不断 代码维护难代码功能耦合在一起新人不知道何从下手 部署不灵活构建时间长任何小修改必须重新构建整个项目这个过程往往很长 稳定性不高一个微不足道的小问题可以导致整个应用挂掉 扩展性不够无法满足高并发情况下的业务需求 微服务架构 微服务是指开发一个单个小型的但有业务功能的服务每个服务都有自己的处理和轻量通讯机制可以部署在单个或多个服务器上。微服务也指一种种松耦合的、有一定的有界上下文的面向服务架构。也就是说如果每个服务都要同时修改那么它们就不是微服务因为它们紧耦合在一起如果你需要掌握一个服务太多的上下文场景使用条件那么它就是一个有上下文边界的服务这个定义来自DDD领域驱动设计。 相对于单体架构和SOA它的主要特点是组件化、松耦合、自治、去中心化体现在以下几个方面 一组小的服务
服务粒度要小而每个服务是针对一个单一职责的业务能力的封装专注做好一件事情。 独立部署运行和扩展
每个服务能够独立被部署并运行在一个进程内。这种运行和部署方式能够赋予系统灵活的代码组织方式和发布节奏使得快速交付和应对变化成为可能。 独立开发和演化
技术选型灵活不受遗留系统技术约束。合适的业务问题选择合适的技术可以独立演化。服务与服务之间采取与语言无关的API进行集成。相对单体架构微服务架构是更面向业务创新的一种架构模式。 独立团队和自治
团队对服务的整个生命周期负责工作在独立的上下文中自己决策自己治理而不需要统一的指挥中心。团队和团队之间通过松散的社区部落进行衔接。 我们可以看到整个微服务的思想就如我们现在面对信息爆炸、知识爆炸是一样的通过解耦我们所做的事情分而治之以减少不必要的损耗使得整个复杂的系统和组织能够快速的应对变化。 我们为什么采用微服务呢 让我们的系统尽可能快地响应变化 - Rebecca Parson 让我们的系统尽可能快地去响应变化。其实几十年来我们一直在尝试解决这个问题。如果一定要在前面加个限制的话那就是低成本的快速响应变化。上世纪90年代Kent Beck提出要拥抱变化在同期出现了诸多轻量级开发方法诸如 XP、Scrum2001年敏捷宣言诞生之后又出现了精益、看板等新的管理方式。如果说这些是为了尽快的响应变化在软件开发流程和实践方面提出的解决方案那么微服务架构就是在软件技术和架构层面提出的应对之道。 image 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 服务之间如何通信
2016102726 一般同步调用比较简单一致性强但是容易出调用问题性能体验上也会差些特别是调用层次多的时候。RESTful和RPC的比较也是一个很有意 思的话题。一般REST基于HTTP更容易实现更容易被接受服务端实现技术也更灵活些各个语言都能支持同时能跨客户端对客户端没有特殊的要 求只要封装了HTTP的SDK就能调用所以相对使用的广一些。RPC也有自己的优点传输协议更高效安全更可控特别在一个公司内部如果有统一个 的开发规范和统一的服务框架时他的开发效率优势更明显些。就看各自的技术积累实际条件自己的选择了。而异步消息的方式在分布式系统中有特别广泛的应用他既能减低调用服务之间的耦合又能成为调用之间的缓冲确保消息积压不会冲垮被调用方同时能 保证调用方的服务体验继续干自己该干的活不至于被后台性能拖慢。不过需要付出的代价是一致性的减弱需要接受数据最终一致性还有就是后台服务一般要 实现幂等性因为消息发送出于性能的考虑一般会有重复保证消息的被收到且仅收到一次对性能是很大的考验最后就是必须引入一个独立的broker如 果公司内部没有技术积累对broker分布式管理也是一个很大的挑战。 2016102729 微服务优点
每个微服务都很小这样能聚焦一个指定的业务功能或业务需求。
微服务能够被小团队单独开发这个小团队是2到5人的开发人员组成。
微服务是松耦合的是有功能意义的服务无论是在开发阶段或部署阶段都是独立的。
微服务能使用不同的语言开发。
微服务允许容易且灵活的方式集成自动部署通过持续集成工具如Jenkins, bamboo 。
一个团队的新成员能够更快投入生产。
微服务易于被一个开发人员理解修改和维护这样小团队能够更关注自己的工作成果。无需通过合作才能体现价值。
微服务允许你利用融合最新技术。
微服务只是业务逻辑的代码不会和HTML,CSS 或其他界面组件混合。
微服务能够即时被要求扩展。
微服务能部署中低端配置的服务器上。
易于和第三方集成。
每个微服务都有自己的存储能力可以有自己的数据库。也可以有统一数据库。
微服务架构的缺点
微服务架构可能带来过多的操作。
需要DevOps技巧 (http://en.wikipedia.org/wiki/DevOps).
可能双倍的努力。
分布式系统可能复杂难以管理。
因为分布部署跟踪问题难。
当服务数量增加管理复杂性增加。
需要考虑的问题
单个微服务代码量小易修改和维护。但是系统复杂度的总量是不变的每个服务代码少了但服务的个数肯定就多了。就跟拼图游戏一样切的越碎越难拼出整幅图。一个系统被拆分成零碎的微服务最后要集成为一个完整的系统其复杂度肯定比大块的功能集成要高很多。
单个微服务数据独立可独立部署和运行。虽然微服务本身是可以独立部署和运行的但仍然避免不了业务上的你来我往这就涉及到要对外通信当微服务的数量达到一定量级的时候如何提供一个高效的集群通信机制成为一个问题。
单个微服务拥有自己的进程进程本身就可以动态的启停为无缝升级的打好了基础但谁来启动和停止进程什么时机选择在哪台设备上做这件事情才是无缝升级的关键。这个能力并不是微服务本身提供的而是需要背后强大的版本管理和部署能力。
多个相同的微服务可以做负载均衡提高性能和可靠性。正是因为相同微服务可以有多个不同实例让服务按需动态伸缩成为可能在高峰期可以启动更多的相同的微服务实例为更多用户服务以此提高响应速度。同时这种机制也提供了高可靠性在某个微服务故障后其他相同的微服务可以接替其工作对外表现为某个设备故障后业务不中断。同样的道理微服务本身是不会去关心系统负载的那么什么时候应该启动更多的微服务多个微服务的流量应该如何调度和分发这背后也有一套复杂的负载监控和均衡的系统在起作用。
微服务可以独立部署和对外提供服务微服务的业务上线和下线是动态的当一个新的微服务上线时用户是如何访问到这种新的服务这就需要有一个统一的入口新的服务可以动态的注册到这个入口上用户每次访问时可以从这个入口拿到系统所有服务的访问地址。这个统一的系统入口并不是微服务本身的一部分所以这种能力需要系统单独提供。
还有一些企业级关注的系统问题比如安全策略如何集中管理系统故障如何快速审计和跟踪到具体服务整个系统状态如何监控服务之间的依赖关系如何管理等等这些问题都不是单个微服务考虑的范畴而需要有一个系统性的考虑和设计让每个微服务都能够按照系统性的要求和约束提供对应的安全性可靠性可维护性的能力。
image API为什么很重要
•服务价值的精华体现
•可靠、可用、可读
•只有一次机会 image 实现一个API网关作为所有客户端的唯一入口。API网关有两种方式来处理请求。有些请求被简单地代理/路由到合适的服务上其他的请求被转给到一组服务。 相比于提供普适的APIAPI网关根据不同的客户端开放不同的API。比如Netflix API网关运行着客户端特定的适配器代码会向客户端提供最适合其需求的API。 API网关也可以实现安全性比如验证客户端是否被授权进行某请求。 设计要素
•Version
•RequstID
•AuthSignature
•RateLimit
•Docs
•ErrorCodeMessage image 微服务治理
•按需伸缩
–
