标签：实例 tomat proxy with 进程 sms hit 基础设施 XML
目录
传统IT架构面临的一些问题：
对于企业：
对于产品：
此外，从技术方面看，云计算及互联网公司大量开源轻量级技术不停涌现并日渐成熟：
这一切都催生了新的架构设计风格 – 微服务架构的出现。
参考2014年3月Martin Fowler关于微服务架构的文章。微服务架构是一种架构模式，它提倡将单一应用程序划分成一组小的服务，服务之间互相协调、互相配合，为用户提供最终价值。每个服务运行在其独立的进程中，服务与服务间采用轻量级的通信机制互相协作（通常是基于HTTP协议的Restful API）。每个服务都围绕着具体业务进行构建，并使用自动化布署工具进行独立的发布。可以有一个非常轻量级的集中式管理来协调这些服务，可以使用不同的语言来编写服务，也可以使用不同的数据存储。
In short, the microservice architectural style [1] is an approach to developing a single application as a suite of small services, each running in its own process and communicating with lightweight mechanisms, often an HTTP resource API. These services are built around business capabilities and independently deployable by fully automated deployment machinery. There is a bare minimum of centralized management of these services, which may be written in different programming languages and use different data storage technologies.
微服务架构 ≈ 模块化开发 + 分布式计算
通用特性:
通过服务实现应用的组件化围绕业务能力组织服务 每个微服务仅关注于完成一件任务并很好地完成该任务。每个任务代表着一个小的业务能力。 因相同原因而变化的功能聚合到一起，而把因不同原因而变化的功能分离开智能端点与管道扁平化去中心化 使用合适的工具完成各自的任务基础设施自动化| 架构 | 优点 | 缺点 | 适用场景 |
|---|---|---|---|
| 单体应用 | 1. 开发简单直接，集中式管理 2. 功能都在本地，没有分布式的管理开销和调用开销 |
1. 随着项目增大，会带来开发效率低，代码维护难，部署不灵活的问题 2. 扩展性不足（横向的硬件资源扩展和纵向的功能扩展） |
小项目，临时项目 |
| 微服务 | 1. 降低系统复杂度。单体应用分解为一组服务，每个服务都比较简单，只关注于一个业务功能 2. 松耦合，服务可独立开发 3. 跨语言，选择合适的语言和技术，并且易于重构和升级 4. 服务可独立部署，使得持续集成和部署成为可能也是必须 5. 服务可独立扩展，根据服务特性选择硬件资源 6. 和 Docker 容器结合的更好 |
1. 分布式使服务间的调用，通信，跟踪变的复杂 2. 分区的数据库体系和分布式事务 3. 服务数量多，系统碎片化。必须考虑到部署，管理问题 4. 跨多个服务的更改需要仔细规划和协调 |
大且业务复杂度高的项目， 需要长期演进的项目 |
| 架构 | 相同点 | 差异点 |
|---|---|---|
| SOA | 以服务为核心 | SOA更关注企业规模范围，强调的是异构系统之间的通信和解耦合。 重ESB 以Web Service/BMP/ESB等技术为主 |
| 微服务 | 以服务为核心 | 微服务架构则更关注应用规模范围，强调的是系统按业务边界做细粒度的拆分和部署。 微服务甚至是去ESB、去中心化、分布式 采用许多新的开源技术和经验 |
但是显而易见，无论是Dubbo还是Spring Cloud都只适用于特定的应用场景和开发环境，它们的设计目的并不是为了支持通用性和多语言性。并且它们只是Dev层的框架，缺少DevOps的整体解决方案（这正是微服务架构需要关注的）。
2017 年底，非侵入式的 Service Mesh 技术从萌芽到走向了成熟。译作“服务网格”，作为服务间通信的基础设施层。可以将它比作是应用程序或者说微服务间的 TCP/IP，负责服务之间的网络调用、限流、熔断和监控。
Service Mesh有如下几个特点：
目前流行的Service Mesh开源软件有Linkerd，Envoy，Istio，Conduit等。
Linkerd和Envoy比较相似，都是一种面向服务通信的网络代理，均可实现诸如服务发现、请求路由、负载均衡等功能。它们的设计目标就是为了解决服务之间的通信问题，使得应用对服务通信无感知，这也是Service Mesh的核心理念。Linkerd和Envoy像是分布式的Sidebar，多个类似Linkerd和Envoy的proxy互相连接，就组成了service mesh。
而Istio则是站在了一个更高的角度，它将Service Mesh分为了Data Plane和Control Plane。Data Plane负责微服务间的所有网络通信，而Control Plane负责管理Data Plane Proxy。Conduit定位和功能与Istio类似。
标签：实例 tomat proxy with 进程 sms hit 基础设施 XML
原文地址：https://www.cnblogs.com/royzshare/p/9378376.html
