Series:
Index List: nine analyze with you easily complete explosion istio Service Grid Tutorial Series
table of Contents
1 Introduction
2 Evolution of Architecture
2.1 single architecture
2.2 vertical architecture
2.3 micro Services Architecture
Evolution history of 3 micro Services Architecture Model
And a communication frame 3.1
3.2 run-time support services
Services Security 3.3
3.4 Monitoring and alerting service
3.5 Service Deployment
3.6 underlying service
3.7 Protection Service
3.8 Link-pressure measurement
4 micro-service architecture model panorama
5 problems caused by
5.1 is not unified service governance
5.2 Repeat-create the wheel
5.3 Service Governance lack of standardization
Summary 6
1 Introduction
Before introducing istio, speaking first micro-services, because istio is developed in micro-technology service system. When you have a reasonable grasp of micro system technology services, come back and understand istio, you will really feel technology is moving forward all the way heritage.
History will repeat, but the technology never move forward.
In this paper I have a lot of content from multiple ppt screenshot after the company's technology to share, if you're interested ppt, you can ask me.
2 Evolution of Architecture
2.1 single architecture
Features:
1 All functions are integrated in a project engineering
2 all the features packed in a bag deployed to the web server
3 separate applications with database deployment
4 to improve system performance by deploying Application Clusters and cluster database
advantage:
Simple structure, low upfront development cost, short cycle. Choice for small projects.
Disadvantages:
1 All functions are integrated in a project for large-scale projects is not easy to develop, expand and maintain
2 System performance can only be extended by extending clusters, high costs
3 technology stack is limited
2.2 vertical architecture
Features:
When the traffic gradually increased, a single application of price increases brought the machine smaller and smaller, the application is split into several applications unrelated to improve efficiency.
advantage:
1 related architecture simple, low upfront development cost, short cycle, the first choice for small projects
2 by the vertical resolution, the original monomers will not expand infinitely
3 different projects stacks may employ different techniques
Disadvantages:
1 integrated with the business domain function in a project, for large projects is not easy to develop, expand and maintain the high costs
2 系统性能扩展只能通过扩展集群，成本高，有瓶颈
3 单体之间的函数调用过度到系统之间的 rpc 或者 http 调用，服务发现需要单独机制保证
2.3 微服务架构
特点：
1 将系统服务层完全独立出来，并将服务层抽取为一个个微服务
2 微服务遵循单一原则
3 微服务之间采用 RESTful轻量级协议进行传输
优点：
1 服务拆分粒度更细，有利于资源重复利用，提高开发效率
2 可以更加精准指定每个服务的优化方案，提高系统的可维护性
3 微服务架构采用去中心化思想，服务之间采用 RESTful 等轻量级协议通信，相比 ESB 更轻
4 适合互联网产品，产品迭代更加快速和便捷
缺点：
1 微服务过多，服务治理成本高，不利于系统维护
2 分布式系统开发的技术成本高（容错、分布式事务等），对团队技术挑战大
3 微服务架构模型演进史
微服务架构的模型也是一个从简单到复杂的演进过程。
3.1 框架与通信
微服务架构初期，主要的技术诉求是寻找更简单和轻量的开发框架，不同的开发框架意味着采用不同的通信协议。
3.2 运行时的支撑服务
当服务的编写和通信解决了之后，接下来就要考虑一些运行时的支撑服务了。这些服务跟业务去耦，属于基础层的支撑服务，比如网关、负载均衡、服务注册与发现、配置中心等。
3.3 服务安全
解决了服务的通信以及基础支撑后，大体上业务就可以开展了。但是这样裸奔的服务是有很大安全风险的，很多敏感的信息在不经过认证和授权就可以轻易获取到，因此服务安全就加入到了微服务的模型体系中。服务安全主要有两种，分别是 jwt 和 oauth2。
3.4 服务监控和告警
服务在解决了通信、支撑和安全之后，就可以愉快地展开工作了。但就跟判断健康需要做体检一样，判断在线服务是否健康就需要监控和遥测，当工作负载超过了阈值就要告警通知人为介入。服务的监控有很多的维度，常见地有系统指标监控、业务指标监控、服务健康检查、调用链监控、日志监控等。
3.5 服务部署
容器化时代带来了新的运维思路，原有基于虚拟机、物理机的重运维开始向基于容器以及容器编排的轻运维转换，这种转换也带来了服务部署方式的改变。更快、更好、更有效的部署成为微服务架构模型新的挑战。
服务部署需要解决的问题有发布机制的引入、镜像治理、容器治理、卷管理、CI/CD 等方面。
3.6 底层服务
当业务范围越来越广，再大的公司也不可能解决任何技术问题，这时就需要引入一些业界优秀的第三方服务作为底层服务来解决特定问题。有时这些第三方服务并不可能完全适合自己的架构，因此就需要做适当的剪裁。尽管如此，这些第三方服务也构成了整个微服务架构模型中不可或缺的一部分。常用的第三方底层服务有分布式消息中间件、分布式数据访问、分布式任务调度和分布式缓存等。底层服务跟基础支撑服务的区别在于前者更多在业务问题域，而后者则主要是通用问题域。
3.7 服务防护
就像胃口再好的人也不可能一次吃下整头大象一样，编写再好的服务也不可能支持无限的请求。技术人员在处理无限、不可期技术场景的技术方案时，经常的策略是以不变应万变：根据目前的服务负载设置峰值，超过峰值就进行熔断、限流等措施。
熔断如下图所示：
降级如下图所示：
限流如下图所示：
3.8 全链路压测
在上面的介绍中，我们介绍了微服务架构模型的各个维度。本来可以在这里结束，但是想想实在不妥，因为我们缺少了很关键的一环，那便是测试。
全链路压测是稍具规模的科技公司都必须要做的工作之一。它的重要性不言而喻，当业务发展超出预期，系统要具有先知先觉的能力以抵御洪灾。毕竟未雨绸缪总好过亡羊补牢。全链路压测是一个大的话题，因为这里介绍的是 istio，故这里一笔带过，有关 ppt 详情我也照顾篇幅不再赘述，如果有朋友对此感兴趣，可以向我索要。
4 微服务架构模型全景图
下图展示了整个微服务架构模型：
5 带来的问题
The introduction of micro-services architecture brings many benefits, but it also brings many problems of governance services. The core question is as follows:
5.1 is not unified service governance
Different services will introduce different ways of governance of middleware, and technical standards and maintain these standards middleware is different. Therefore, operation and maintenance personnel or infrastructure must master the use of each middleware, many times this is not the reality of limited human resources of a technology company.
5.2 Repeat-create the wheel
Micro-service architecture allows multiple language stack, multi-technology stack, but a different technology stack for common technical problems of communication, support services, service security, service monitoring, fuse / downgrade / current limiting, but requires its own solution, it is the cost of waste.
5.3 Service Governance lack of standardization
Due to the lack of standardized service management, quality of service and therefore the micro-management of the whole technical staff rely on personal ability, experience and levels, which is something like a workshop era, thanks to high-quality artisan objects. But no standardization is clearly inconsistent with the trajectory of technological development.
Summary 6
Micro-services development is now stabilized and become a mainstream technology, but at the same time it has become increasingly embarrassing situation, the problems exposed more and more acute. Fortunately, the service grid era, the leader istio service grid is steadily entering the stage of history, and become more and more hot. IX below analysis will continue to take you easily complete explosion istio.