找回密码

开发笔记 第108页

记录了我开发过程中遇到的问题和资料

.NET Core with 微服务 - 什么是微服务 - Agile.Zhou - 博客园

mikel阅读(835)

来源： .NET Core with 微服务 – 什么是微服务 – Agile.Zhou – 博客园

微服务是这几年最流行的架构，说起架构不提微服务都不好意思跟人家打招呼。最近想要再梳理一下关于微服务的知识，并且结合本人的一些实践经验来做一些总结与分享。前面会分享一些概念性的东西，后面也会使用.net来实践，一步步完成一个简单的微服务架构的小demo。

什么是微服务

其实微服务并没有统一的标准定义。微服务是一种软件架构的风格。它首先由大神martin fowler提出，2014年3月25号在他的博客上发表了一篇博客来描述了这种微服务的架构。原文地址（https://www.martinfowler.com/articles/microservices.html）。
相对于传统的单体（Monolithic）架构应用，微服务把单个进程的应用拆分为多个单独部署的服务。每个服务对外提供一些接口来进行服务间的通讯或者对第三方提供功能。每个独立的服务甚至使用自己独立的存储技术，独立的语言技术栈。说到底微服务架构还是贯彻了软件开发中：单一职责、分而治之、解耦等基本理念，只是它把这种理念从类、类库级别提升到了进程级别。

图片引用自https://www.redhat.com/zh/topics/microservices/what-are-microservices

微服务与SOA

微服务架构看起来跟SOA架构非常相似。事实上微服务架构就是SOA的一种现代化的实现方式，一次进化。虽然不能在两者之间画等号，但是他们的思想确实是一致的。

图片引用自https://zato.io/docs/intro/esb-soa-cn.html

微服务与SOA之间的区别网上有很多，在此不再大段的复制黏贴网上现成的文字，简单谈谈自己的一些理解。
首先SOA大多数情况下是作用于企业内部，它通过ESB等总线技术把企业内的服务（或者称之为应用）串联起来。SOA虽然是在解耦、去中心化，但是它通常跟某种ESB技术强耦合起来，以至于ESB会成为那个最大的中心。微服务的作用范围是应用而不是庞大的企业。微服务不在依赖ESB等总线技术，服务间的通讯通过无状态、轻量级的接口实现。协议采用http、json等通用协议无关开发语言，谁都可以调用。所以相比SOA有更好的去中心化意义。

优点

上面说了这么多关于微服务的知识，那么实施微服务到底为我们带来了哪些好处？网上有很多复制黏贴的话其实我不太苟同，比如：部署简单，如果没有强大的运维团队微服务的部署显然是比传统单体应用部署难度更大了。 比如快速开发快速迭代：事实上单体应用也不用等到完全开发完才能上线。下面说下我认为的微服务的几个优点：

  1. 技术异构
    采用微服务架构可以很方便的在每个服务中使用不同的技术栈。每个团队可以根据自身的业务情况，人员情况安排使用最合适的技术。如果我们服务业务是AI那就考虑pyhton，如果我们的人员比较熟悉JavaScript，那么可以选nodejs。当然技术的多样性也是要权衡的，不能说每个服务都撸一种语言每个都试验一把，这样未必就是好事情了。
  2. 扩展性
    当我们的业务做的越来越大，流量越来越大的时候，需要对计算资源进行扩展。相对于单体应用，微服务可以更好的进行扩展。传统单体应用水平扩展的时候可能需要把整个应用都扩展多个实例。事实上我们的业务越来越大的时候，往往只是某个模块压力巨大。而采用微服务架构我们只需要对某压力大的服务进行水平扩展。配合现在的容器化技术能够更好的利用技术资源。
  3. 可靠性
    由于每个服务都是独立部署，当某个服务故障的时候通常不会导致其它服务同时故障，只是丧失了部分能力。再配合服务降级、熔断等技术可以比单体应用提供更好的可靠性。
  4. 强模块化边界
    这个概念在网上很少出现。我是在B站上杨波老师的一个关于微服务视频上看到的，对这个观点比较认同。模块化是我们软件开发常用的模式。原来我们按类、按类库进行模块化，现在通过微服务架构直接把模块服务化了，并且能独立部署运行。其它模块不在需要直接引用相关类库就可以使用它。而且实施微服务架构后会强制团队进行应用的模块化，对模块的边界进行明确的划分。当然模块的边界划分是个技术活，如果划分的不够好那就是场灾难。

缺点

这个世界上的事情都是具有两面性的。微服务除了有其优点，自然也有缺点。我们在做架构的时候要尽量处理好这些缺点，避免踩到巨坑。下面谈谈我对微服务缺点的一些看法。

  1. 运维难度增加
    本来只需要部署一个IIS站点或者Tomcat服务、维护一个数据库，现在变成了需要部署N个不同的服务，N个不同类型的数据库。不同的服务甚至可能分散在不同的服务器上。要使这些服务正常的工作，正常的通讯，还要对其进行监控显然比单体架构时代对运维的考验提高了一个维度。没有强大的运维团队、自动化的运维工具的话微服务实施起来出故障的概率显然会大大增加。
  2. 分布式的挑战
    微服务架构天然就是分布式的。但是分布式系统会带来很多单体架构没有的问题。比如分布式事务，数据一致性问题。本来在进程内一个锁或者在数据库开一个事务就能解决的事情，现在不得不借助分布式锁、分布式事务、数据最终一致性来处理。这些问题对开发人员写代码的时候也是很大的挑战。除了一致性的问题，微服务架构中服务之间的通信也会有很高的成本。本来进程内的方法调用变成了跨进程、跨服务的通讯。我们知道网络是不可靠的，出现故障的概率远远超过进程内调用。
  3. 调试，测试难度增加
    由于服务之间互相依赖，在做集成测试或者调试的时候需要把所有依赖的服务、数据库等全部都跑起来。出现问题很难一次性定位到确切位置。由于服务器之间网络带宽的原因多次测试结果可能会有变动，测试的结果不稳定。
  4. 沟通成本提高
    在采用微服务架构开发之后，团队的组织架构都可能跟着变动，团队免不了被拆分成多个小团队甚至不同部门。在公司呆过的都知道，跨团队跨部门之间沟通的成本有多大。本来一天就能修复的bug，很可能变成一周。
  5. 模块划分困难
    我们前面说微服务把每个模块进行独立部署，采用独立的数据库。这么轻描淡写的一句话，事实上实施起来并没有那么容易。如果模块划分的不好，那么会出现非常多的跨库查询，非常多的跨库事务。本来单体架构上很简单的事情变得无比复杂。本来一句Transaction就你搞定的事情，现在可能需要先团队之间进行沟通，然后互相开接口，再使用分布式事务来完成。模块划分的一个好的方案就是采用DDD的思想进划分，但是事实上能把DDD玩好落地也不是一件容易的事。

微服务不是银弹

微服务这几年火热的很。很多公司、架构师言架构必微服务，好像微服务是包治百病的良药。不管项目大小，项目周期，人员配置，技术实力，一股脑的上微服务。见过3，5人小团队一个月就能开发上线的说要进行微服务改造。这么做怕不是微服务真的香，而是为了充实自己的简历。
微服务不是银弹，正如上面所述，微服务在享受它带来的好处的时候也是有巨大的成本开销的。它会带来组织架构上的变动，人员的变动。它大大的提高了系统的复杂性，给运维、开发、测试、调试都带来巨大的挑战。
在采用微服务架构之前最好先思考一下，真的需要微服务吗？权衡一下微服务带来的利弊再下决定。以我个人的经验来看，市面上绝大多数系统更适合单体架构，或者说没必要一上来就采用微服务架构。真正好的架构是在满足当前需求的前提下快速稳定的上线，并对后面的扩展、改造留好余地，以应对后面业务发展带来的需求进行架构的升级改造。

总结

通过以上这些铺垫我们讲了微服务的概念、微服务有哪些优点、微服务又有哪些缺点给我们带来了哪些方面的挑战。以上是我个人的一些浅薄的理解有可能有遗漏或者有错误，大家可以一起讨论一下。
下一篇将会对微服务架构、微服务使用的常用组件进行详细介绍，敬请期待。
谢谢阅读，帮忙点赞。

HTTP 错误 403.14 - Forbidden Web 服务器被配置为不列出此目录的内容 - 笑笑未来 - 博客园

mikel阅读(795)

来源： HTTP 错误 403.14 – Forbidden Web 服务器被配置为不列出此目录的内容 – 笑笑未来 – 博客园

一、错误

HTTP 错误 403.14 – Forbidden Web 服务器被配置为不列出此目录的内容，如图所示：

 

二、解决方法：

1、在web.config中加:<modules runAllManagedModulesForAllRequests=”true”/>

需要在modules配置中添加属性runAllManagedModulesForAllRequests，还有.net的版本，如图所示：

 

2、重新注册一下.net framework4.0（HTTP 错误 500.21 – Internal Server Error ）

32位的Windows：
—————————————————————————
1. 运行->cmd

2. cd  C:\Windows\Microsoft.NET\Framework\v4.0.30319

3. aspnet_regiis.exe -i

 

64位的Windows：
—————————————————————————
1. 运行->cmd

2. cd  C:\Windows\Microsoft.NET\Framework64\v4.0.30319

3. aspnet_regiis.exe -i

 

 

 

参考地址：https://blog.csdn.net/sinat_34719507/article/details/63918365

我是一个爱笑，认真记录每一天进步的博主. 转载请注明出处，商用请征得作者本人同意，谢谢！！！

在iis上部署asp mvc5 程序_吕刚的博客-CSDN博客

mikel阅读(857)

来源： 在iis上部署asp mvc5 程序_吕刚的博客-CSDN博客

碰到的问题

1.

第一个问题出现：

HTTP Error 500.19 – Internal Server Error
配置错误: 不能在此路径中使用此配置节。如果在父级别上锁定了该节，便会出现这种情况。锁定是默认设置的(overrideModeDefault=”Deny”)，或者是通过包含 overrideMode=”Deny” 或旧有的 allowOverride=”false” 的位置标记明确设置的。
出现这个错误是因为 IIS 7 采用了更安全的 web.config 管理机制，默认情况下会锁住配置项不允许更改。要取消锁定可以运行命令行 %windir%\system32\inetsrv\appcmd unlock config -section:system.webServer/handlers 。其中的 handlers 是错误信息中红字显示的节点名称。
如果modules也被锁定，可以运行%windir%\system32\inetsrv\appcmd unlock config -section:system.webServer/modules

注意：cmd.exe要以管理员身份启动，在c:\windows\system32下找到cmd.exe，右键管理员启动，输入上面的命令即可。

转自http://blog.csdn.net/bdmh/article/details/8088487

2.然后出现了

Post MVC on IIS 7 error: 403.14-Forbidden Web server is configured to not list the contents of this directory

Toss for a long time, prompt solution is:

  • If you do not wish to enable directory browsing, make sure you have configured the default document and the file exists.
  • Use IIS Manager to enable directory browsing.
    1. Open the IIS Manager.
    2. In the “function” view, double-click the “directory browsing”.
    3. In the “directory browse” page in the “actions” pane, click “enable”.
  • Confirm the site or application’s configuration/system.webServer/directoryBrowse@enabled property is set to True in the configuration file.

Under the reform, found running interfaces in a Web page into a directory structure, and later found the profile configuration section of the Web.config configuration file, the sites can be used to record.

<system.webServer>
<modules runAllManagedModulesForAllRequests=”true” />
</system.webServer>

To set the <modules> value to true, directory browsing enabled or disabled are not affected.

转自：http://www.cnblogs.com/shanyou/archive/2012/07/01/2572273.html

3.然后出现了

还是不行，百度又没有好的回答。

最后发现好像我的iis 没有配置好，连ASP.NET一节都没有，在程序管理里重新配置，然后重启，ok了。

配置这篇文章http://www.codeproject.com/Articles/674930/Configuring-IIS-ASP-NET-and-SQL-Server

貌似 SQL server express 版本没法用。然后自动创建的数据库版本为706，也就是要SQL server 2012才能打开。
走了很多的弯路，数据库终于没问题了。总结下，
1.用vs 2013 code first 自动创建的mdf没法附加到SQL server 2008，2008版本太低了。于是又下载安装了SQLServer 2012
2.可能是因为安装了sql server express 等的愿意 ，默认 1433端口 telnet 不通，在2012里看到默认采用了动态端口。这么高大上的东西，没耐心去研究，去掉动态端口，从新采用tcp端口 1433，重启SQLServer 。telnet 通了。
3.修改web.config中的链接字符串，不过还要在dbcontext上下文中改下。一直没改对，都是默认在app-data下创建mdf文件。其实很简单。base()的参数是连接字符串即可。
如下
public class cmsContext:DbContext
{
public cmsContext() : base(ConfigurationManager.ConnectionStrings[“tenhours.cmsContext”].ToString()) { }
public DbSet<Course> Courses { get; set; }
web.config中代码如下：
<connectionStrings>

<add name=”tenhours.cmsContext” connectionString=”Server=192.168.11.2\SQLServer2012;Database=tenhours.DAL.cmsContext;User ID=sa;Password=bright623″  providerName=”System.Data.SqlClient” />
</connectionStrings>

做的过程中不小心把默认的defaultconnection 删掉了，那个是默认提供的登录模块用的。先不管了，后面配置用户模块的时候再说吧。
下面的问题是上传文件大小限制的错误
[HttpException (0x80004005): 超过了最大请求长度。]
处理方法是在web.config中配置。前面搜索过很多坑爹的解决方法。叹。
 <system.web>
<authentication mode=”None” />
<compilation Debug=”true” targetFramework=”4.5″ />
<httpRuntime targetFramework=”4.5″ maxRequestLength=”9000″  executionTimeout=”3600″ />

</system.web>

只要配置下httpruntime 的maxRequestlenght 就可以了。9000代码9000kb，如果希望最大允许30M 则设置为30*1024即可。或者30000近似下。
同时也需要设置下httpruntime 的timeout属性。
iis默认的用户，没有对目录的操作权限。好像没有aspnet用户。不知道又哪里错了，查了下，aspnet用户被替换成network service了。不过iis里匿名链接用的不是network service用户，所以需要改下。把网站的身份验证选择为应用程序池标识。然后修改对应应用程序池的内置账户为network service，在应用程序池的高级设置 进程模型 标识 项
具体请参见

Meteor+AngularJS：超快速Web开发 - 侯振宇 - 博客园

mikel阅读(829)

来源： Meteor+AngularJS：超快速Web开发 – 侯振宇 – 博客园

   为了更好地描述Meteor和AngularJS为什么值得一谈，我先从个人角度来回顾一下这三年来WEB开发的变化：
    三年前，我已经开始尝试前后端分离，后端使用php的轻量业务逻辑框架。但当时前端还没有成熟且广泛流行的业务逻辑框架。所以在做产品开发时我仍然选用drupal等整体开发框架。开发时常常需要在JavaScript和php间切换，同时还要自己搞定数据库。此时的开发模型图是这样（红色箭头和红色块都表示工作重灾区）：
    随着对用户体验的追求，我开始把业务逻辑往前端推移，于是马上遇到了前端数据与页面展示绑定的问题，业务逻辑简单时还能用JQuery搞定。越来越复杂后，开始尝试使用backbone等前框架来规范数据层和做数据与视图的绑定，用requireJS做模块化和延迟加载。同时异步处理等编程模型也都开始进入实战。后端采用RESTful接口规范。此时的开发模型图是这样：
    一年前左右，接触到knockout和AngularJS，感受到数据和视图自动绑定的美妙开发体验后，立即抛弃Backbone。此时的开发已经彻底前后分离、前端业务数据层和视图层分离。接下来又开始陆续使用coffeescript 、jade、less进一步减少代码量。用grunt做自动编译、测试、和检测文件改动自动刷新浏览器。一切都已经比较完美了，除了后端仍然要对数据持久化做不少工作，除了前端要想实时反映数据改变仍然要轮询或者用webSocket连接服务器。这时的开发模型图已经是这样了：
    只差一点就完美了，Meteor就是这一点。Meteor是一个基于nodejs、webSocket、mongoDB的整体开发框架，在它的实现中，前后端的数据模型已经几乎没有差别。
    意思就是，前端对数据模型进行任何改动，只要调用“save”方法，所有数据就自动存到服务器端的mongoDB中了——终于可以忘了主动发送请求给服务器，终于可以忘了服务器要和前端实现几乎一样的数据模型层
    而任何前端“订阅的”后端数据出现改动，前端数据模型也会马上自动得到了更新——终于可以忘了主动轮询，终于可以忘了拿到后端数据再解析成前端模型。除了前后端模型的双向自动绑定，Meteor同时还实现了数据到前端模板的自动更新。
    不过，Meteor的模板在处理视图到模型的改动时扩展性不如AngularJS。因此，将AngularJS和meteor结合是最好的选择。到这里，快速Web开发模型终于完成：
    除了模型的自动绑定与更新，meteor还提供了大量进一步加速开发的机制。如：
  • 前后端载入文件文件的自动化管理。只要将相应的文件扔到前后端相应的目录中，就会自动载入到页面，或者在后端自动运行。
  • “智能包”管理。Meteor提供了模块的机制，让第三方开发者可以写“智能包”来加强前后端的功能。如，加载了“coffeescript”智能包后。无论前后端用coffeescript写的代码都会自动编译成JavaScript后再载入。
  • 内置大量“智能包”，有进一步支持开发的包，如“less”、“underscore”、“coffeescript”，还有通用业务逻辑包。如“账户管理”，而且已经集成主流oauth账号登陆。
  • 自动检测文件改动，自动刷新浏览器。
  • 自动化部署。
    以下马上来看一个实际开发的例子，制作一个为公司录入应聘人员信息的系统。
    需求：
  • 能指派面试官，自动邮件通知。
  • 支持google邮箱登陆。
  • 体验流畅、单页应用。
    开始写业务逻辑之前，我们先开始为准备一些开发工具和环境。首先，我要求能用coffescript代替JavaScript，less代替css。安装完meteor之后，进入项目木文件夹。在命令行中输入如下代码
    meteor create myapp
    meteor add less
    meteor add coffeescript
    然后，我想在前端使用JQuery，和meteor提供的账户系统来支持google oauth授权。继续输入：
    meteor add  JQuery
    meteor add  account-ui
    meteor add  account-google
    最后，将angularJS整合进来：在项目文件夹中创建如下目录层级：
client中的内容会全部自动加载到页面上，具体加载顺序请参考官方文档。server中的文件会在应用启动时自动运行。public中文件将作为静态资源供外部访问。
    因为AngularJS对数据模型改动的检测是通过“dirty check”的方式（见Angular官方文档）。所以要使用插件来让Meteor数据改动能通知到AngularJS，以此触发视图变化。这个插件就是上图中的angular.meteor。
    接下来说用AngularJS的ui-route模块来管理页面路由，将应用变成单页：
    加入“使用google账号”登录的功能：
    当新增一个应聘者时，给面试官发邮件：
    这里应该注意到的是，Meteor对于数据的操作完全是标准的MongoDB语法。剩下的业务逻辑用AngularJS的视图与模型很快就可以实现了，这里不再赘述。
    最后看看系统的效果截图，添加新的应聘人信息：
    面试结果记录：
    总结整个开发过程，可以都看到的是，几乎没有后端开发，只要前端完成，应用基本上就完成了。并且一步就可以使用coffeescript、less等，不再需要自己搭建复杂的开发环境。这样的开发体验，在目前来说，几乎已经到极致了。
    当然，要进入真正产品级开发，Meteor还有一些问题要克服，如“支持多种数据库”，“如何部署到集群”，“实时数据增加了服务器负载”等。好在Meteor目前收到的关注已经特别高，并且有了大量的第三方开发者，进入产品级开发的步伐越来越快。我们完全可以期待，这块拼图成熟之后，将给整个web开发新注入一股强大动力。

SqlDataAdapter.Fill()时超时的一个另类的原因：你的存储过程中有超长的代码或注释吗？_文盲的专栏-CSDN博客

mikel阅读(955)

来源： SqlDataAdapter.Fill()时超时的一个另类的原因：你的存储过程中有超长的代码或注释吗？_文盲的专栏-CSDN博客

最近在研究网站中，使用SQLDataAdapter进行Fill时总超时的问题，使用查询分析器执行，结果秒出，使用SQL Server Profiler跟踪后，得到指令扔到查询分析器里，结果还是秒出，但是在页面执行，就永远是超时，相当纳闷啊

于是把SQL Server Profiler跟踪内容调整了一下

 

主要是追加 SP:Starting和SP:Completed以及SP:StmtStarting和SP:StmtCompleted，追加这个是为了跟踪存储过程递归和触发器内容

然后，跟踪结果一片一片的，慢慢看吧

然后，有一个存储过程的代码片段引起了我的注意

 

在这个存储过程中，有一大段的注释掉的代码，但是问题来了，在这个界面里发现有一行很长的注释代码被分成两行，但第二行没有当做注释处理！我的天啊。。。。

于是先修改下存储过程，看看是不是因为这个注释引起的超时，很简单的处理，把过长的注释内容分成两行注释掉

。。。。。。很无语，页面执行结果变成了秒出

WTF！页面执行存储过程难道和查询分析器执行存储过程时，对代码解析有差别么？好吧，亲身经历了惨痛教训，下次写存储过程我一定不会让一行代码过长！

后边经过多次测试，除了注释可能存在换行现象，超长的代码在观察过程中出现了指令丢失现象

例如 select aa,bb,cc………..xx,yy,zz from table where aa=1 and bb=2

当这个指令过长时，实际执行的可能就是select aa,bb,cc………..xx,yy,zz from table where aa=1，他把and bb=2给吃掉了。。。

所以，不管如何，存储过程、触发器、视图、自定义函数，反正是可以自己写代码的地方，一定注意换行，不要让代码超长。。。。
————————————————
版权声明：本文为CSDN博主「文盲老顾」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/superwfei/article/details/82494273

为企业应用开发提速，写给企业IT部门的低代码开发基础知识 - 葡萄城技术团队 - 博客园

mikel阅读(904)

来源： 为企业应用开发提速，写给企业IT部门的低代码开发基础知识 – 葡萄城技术团队 – 博客园

简介：应用程序开发长期以来一直是IT部门和业务部门面临的问题。 IT部门总是被新的应用程序需求弄得不堪重负。他们不可能完成业务部门想要完成的每一个项目。 同时，业务部门的用户厌倦了等待，并开始完全绕过IT部门。 今天，我们来探索一下“低代码开发”这个概念，并阐述它将如何帮助解决这个问题，为企业应用开发提速。

首先，我要问你一个问题：在你的企业里，应用程序开发工作是否跟得上业务需求？ 当用户需要一个解决方案时，他们要等待多长时间？这个问题是许多企业常见的问题来源。 开发远远落后于需求，用户需要等待数周或数月才能获得新的解决方案。

（开发远远落后于需求，图片来自网络）

 

为什么会这样？

在典型的企业中，开发过程看起来像一个漏斗。 漏斗的顶部是业务用户，漏斗的底部是开发人员。来自业务用户的所有需求都从漏斗顶部流向底部的开发人员……并由此陷入困境。不要误会我的意思，我不是在责怪开发人员。 他们手上的任务量远远超过自己的处理能力，而且情况只会变得更糟。 随着Web端和移动端应用程序的业务需求逐渐上升，而开发现代Web端应用程序所需的技能也随之增长，跟上业务的开发需求变得越来越困难。

 

有什么解决方案？

这些挑战促进了低代码开发平台的发展。 今天，我想在此探索这种不断增长的趋势，并为那些还不熟悉这个概念的人介绍一下低代码的基础知识。

 

“低代码”是什么？

（Forrester Research是世界知名的技术和市场调研公司，图片来自网络）

2014年，Forrester Research提出了“低代码开发”这个术语来描述一种日渐流行的软件工具。 这些工具允许通过可视化GUI（图形用户界面）而不是传统的编码来开发业务应用程序。

当然，这个概念并不新鲜。 你可以追溯到20世纪90年代的RAD和4GL工具。 虽然RAD和4GL工具经常需要使用专有语言，但他们确实可以帮助开发人员更快地开发应用程序。

（使用专用语言快速开发应用的RAD工具）

 

这些旧工具与新工具之间存在巨大的差异： 低代码平台为每个人 —— 甚至是非技术用户 —— 提供了开发功能，而且它们也不需要特定的编码语言，在可视化设计器上通过托拉拽的方式即可开发出包含复杂图表在内的各种页面和业务逻辑。虽然术语“低代码”意味着某种程度上需要写代码，但这些平台基本无需写任何代码就可以开发许多类型的应用程序。 它们被赋予 “低代码”这个术语，完全是因为有些更复杂的项目，比如连接到第三方软件服务活硬件驱动时，可能需要很少量的自定义编码。

（使用低代码的方式构建MES移动端页面）

 

 “低代码”业务为什么会增长？

据《福布斯》杂志报道，到2022年，低代码开发平台的总市场将增长到212亿美元，年增长率为40%。作为一个相对较新的软件类型，他怎样实现了快速增长？

其中大部分原因应该归结为供需关系，上文中我已经解释过了。 比起以往，在数字时代，企业有越来越多的应用程序需求。 他们需要适用于所有平台的应用程序。 最重要的是，随着企业不断尝试提高敏捷性，开发速度越来越重要。

问题是，大多数企业自身的开发人员无法满足当前日益增长的开发需求。 因此，他们面临着以下三个选择：

  1. 依然慢慢地开发应用程序
  2. 雇用更多的开发人员
  3. 采用低代码平台

毫无疑问，很多企业采用了第三种选择，因为它不仅可以减轻当前开发人员的压力，还可以让非开发人员也能自己开发Web端应用程序。

（低代码开发包含可视化设计和编码扩展能力）

 

“企业应该关注低代码开发，因为快速变化的技术领域需要业务敏捷性，我们没有足够多的时间来雇用、培训和留住开发人员来帮助管理大环境下的新兴流程，” 活字格低代码开发平台的产品经理胡耀说到， “当新工作流程和流程需要自动化时，低开发平台可以提供灵活性和速度，并降低成本。”

 

低代码开发对你有怎样的帮助？

 

你所在企业为什么要关心低代码开发？ 它有哪些优势？ 以下列举了一些：

  • 效率：低代码开发可帮助企业利用当前资源提高生产力。 IT部门不会再遇到积压的开发请求。 最终用户也不会因新应用程序而等待数周。
  • 业务改进：由于IT部门不会遇到积压的开发请求，所以他们可以腾出时间自由地处理更关键的任务。 这为技术改进提供了机会，因为IT部门终于可以专注于能够推动业务发展的领域。
  • 控制：由于开发工具受到IT部门的制约，他们仍然可以控制数据和用户访问。 这样可以避免影子IT产生的问题。
  • 降低成本：通过使用低代码开发平台，你可以利用当前资源去完成更多任务。无需引入开发团队或聘请外部援助团队来满足不断增长的需求。

 

低代码工具的使用者是谁？

简短的答案：可以是贵公司的任何人。

较长的答案：不同的人会根据他们的技能和角色以不同的方式使用该工具。 例如，以下是不同角色/技能使用低代码平台的几种方法：

  • 业务分析人员：低代码平台可帮助业务分析人员快速为用户创建应用程序，并为IT部门模拟复杂的应用程序。
  • 开发人员：低代码平台可帮助开发人员更快地交付应用程序，并消除他们积压的开发需求。
  • 最终用户：低代码平台可帮助最终用户在几分钟内创建报表、仪表板和简单应用程序，而无需通过IT部门。
  • IT部门领导：低代码平台可帮助IT部门的领导提供对业务的安全数据访问，延长其当前系统的使用寿命，并提高IT生产力。

以上列表还可以继续，但我相信你已经得到了答案。 低代码开发平台可以（并且应该）在整个企业范围内使用。

 

你可以用低代码平台开发哪些类型的应用程序？

低代码平台可以开发任何类型的企业应用程序，从基本数据增删改查，到移动端应用程序，再到自定义CRM甚至ERP系统，以及介于两者之间的所有内容。

现在，这是否意味着非技术用户可以使用低代码工具来开发任何类型的应用程序？坦率的讲，不一定。

例如，你是否希望非技术用户来开发关键任务系统？大概不会。这并不是说合适的人选无法完成这样的任务，但业务用户通常会将低代码工具用于简单的开发项目，如报表，将电子表格转换为Web端应用程序，工作流程应用程序等等。虽然我见过非专业开发人员使用低代码工具开发一些非常复杂的系统，如上文提到的成都康福德高出租汽车公司，但大多数还是集中在这些类型的项目上。

对于开发人员来说，低代码工具非常适合提高任何项目的开发速度。它们可以帮助开发人员自动化大部分开发过程，只为每个项目留下最少量（如果有的话）的自定义编码。

 

使用低代码开发平台时你应该注意什么？

当然，低代码开发并非没有风险。话虽如此，使用正确的工具和策略可以轻松管理这些风险。使用低代码方法时，需要注意以下几个方面：

 

应用程序安全性

低代码开发平台通常附带安全功能。但是，最终用户可能并不总是知道应该如何在其应用程序中使用这些安全措施。

怎样避免这些问题？首先，让IT部门参与应用程序审核流程。我并不是说每个应用程序都需要IT部门仔细审查。例如，简单的报表或数据查找应用程序通常都没什么问题。但是，如果用户正在开发具有回写功能的、任务关键型的、或办公室外可用的应用程序，则必须进行IT审查。其次，在给任何开发工具授予许可之前应仔细检查其安全选项。 IT部门应该做数据和用户访问权限控制，并为用户生成的所有应用程序设置安全默认值。

 

用户权限

具有广泛权限的新手用户是开发工作的最大风险。请确保只为每个用户提供他们所需的功能，仅此而已。例如，需要使用该工具进行简单报表任务的用户不应该具有创建数据库管理应用程序的能力。

 

数据

你的数据是任何成功的开发工作的基础。除了数据完整性方面的明细需求以外，还有两个重要因素需要解决：

  • 访问：用户应该只能访问他们需要的数据。同样，这也是限制开发工作风险的另一个步骤。
  • 知识：用户应该了解他们的数据以及表结构。如果用户不了解数据在数据库中的组织方式，则无法成功开发所需的应用程序。

 

你该如何评估和选择低代码平台？

与其他任何事情一样，并非所有低代码平台都是没有差别的。在评估不同选项时，除了该平台的功能外，请注意查看以下几个方面：

 

  • 授权：部分平台采用基于用户人数或者并发用户人数的授权方式；也有部分是基于数据表、页面等应用规模授权。选择哪种授权，都取决于有多少人会使用你计划开发出的应用；该应用需要覆盖多少业务场景。
  • 部署：某些平台可用于开发支持本地部署的应用。有些平台则会锁定你，必须将程序和数据放到该平台供应商的服务器上。以下是一些需要注意的重要问题：如果该平台的厂商停止服务会发生什么，正在贵公司运行的应用是否可以继续使用？
  • 分销或OEM：对自己开发的应用程序你有多大的自由度？如果你想分销、白标或销售你开发的应用程序，某些平台压根不支持你这么做，一些平台会收取一定的费用，而其他的可能没有限制。在着手任何事情之前，需要先了解该平台厂商的策略和费用结构。
  • 自定义：你自主开发的应用程序可以自定义到什么程度？你是否可以访问底层代码，或是否被迫通过平台的界面？你可以在界面中添加自定义计算、代码或业务逻辑吗？这些问题的答案因平台而异，扩展性作为低代码平台相比于零代码平台的优势，一定程度上可以决定该软件在你的业务中成功与否。
  • 图形图表：该平台是否包含报表或图表功能？某些平台可以处理应用程序开发，以及BI 、报表、仪表板应用程序；也有些严格用于应用程序开发。如果你的业务需求是BI 或报表方面，请了解这些领域的工具功能。

 

（活字格低代码开发平台内置的部分常规图表与自定义地图）

典型的低代码开发平台有哪些？

本文只列举了三家有代表性的平台进行评测：OutSystems、Mendix与活字格。选取这三个平台，是因为它们或在市场占有率方面，或在技术积累方面各有特色。

Outsystems

Outsystems是较早入局的一家欧洲公司，研发总部位于葡萄牙，两度入选高德纳公司（Gartner）《流动应用程式开发平台魔力象限》研究报告魔力象限“执行能力”纵轴第一名，被誉为该领域的“领导者”。 价格方面，5000+美元/月的价格还是让很多中小公司望而却步，但依然有很多大公司青睐，包括丰田汽车(Toyota)、施耐德电气(Schneider Electric) 等。

（outsystems可视化设计器界面）

Mendix

Mendix是一家荷兰公司，后来被西门子收购，是Outsystems在海外的主要竞争对手，二者在技术架构和服务模式方面极其相近。除了通过订制化组件、模板盈利以外，Mendix还对应用部署收费，且价格高昂，单APP 1875美元/月，2-5个APP公有云5375美元/月，私有云7825美元/月，这样的价格显然不是中小企业所能负担的，因此，Mendix的客户也以苏黎世保险（Zurich）等大企业为核心。

（使用Mendix开发的客户服务系统页面）

 

活字格

活字格是成立于1980年的老牌开发工具厂商——葡萄城为中国市场推出的低代码开发平台。2019年12月发布的《中国企业服务系列研究报告》中，业内权威机构海比研究将活字格列为“低代码开发平台”行业领导者之一。活字格脱胎于专业开发工具，保持了低技术门槛、高开发效率的同时，提供更强的扩展性。用活字格设计界面时，体验类似于Excel，在单元格的辅助下拖拽各种页面元素，然后可视化设置每个元素的样式，上手门槛更低，页面布局更灵活。活字格的内置组件比较丰富，而且针对中国市场的特点，还提供了对接微信、钉钉、百度AI等本土服务的组件，更适合中国企业使用。活字格也开放了组件的编程接口，在国内有庞大的开发者社区支持。

相比于另外两家国外的竞争对手，本土化的活字格支持本地部署，在价格上也更加亲民，一次性买断的价格从8000元人民币起。强大的扩展性和低廉的价格门槛，让活字格的客户覆盖了联通支付等大企业集团，快行线冷链物流等等大型物流公司，以及更多中小型的企业。

（使用活字格开发的出租车运营管理系统页面）

 

小结

以上这些只是低代码开发平台的基础知识，其实，还有很多内容可供介绍。 现在，你可以尝试用免费的活字格低代码开发平台来开启自己的低代码开发之旅。借助简单的教程，用远远少于您过去花费的时间，您就可以构建出美观、易用的Web端和跨平台的移动端应用程序。从此，您也可以帮助到下一个提问“低代码开发是什么？”的人。

本文是由葡萄城技术开发团队发布，转载请注明出处：葡萄城官网

一个浏览器搞定前后端开发的低代码框架正式开放源码啦! - 白菜园 - 博客园

mikel阅读(934)

来源： 一个浏览器搞定前后端开发的低代码框架正式开放源码啦! – 白菜园 – 博客园

本来想尽量做完美一点再开放，但个人能力实在有限，无法专注于实现内置分布式数据库，所以想借助社区的力量来验证与推进。

一、框架设计目标：

简单：能有更多的时间专注于业务领域；

灵活：不能有任何限制，能够灵活扩展；

快速：能够尽可能快的开发应用系统；

二、框架整体结构：

左图为整体结构，右图为每个应用节点的组件结构：

目前关系数据库支持PostgreSQL, NoSQL支持Cassandra or ScyllaDB

三、技术原理浅析：

模型驱动：

框架将应用系统所涉及的数据结构、业务逻辑、用户界面等抽象为各类型的模型，通过组合模型形成完整的应用系统。

虚拟代码：

框架内的服务模型与视图模型的相关代码皆为虚拟代码（类似于伪代码），在保存发布模型时都会经过转换编译为运行时代码，视图模型的代码由IDE的TypeScript执行转换，服务模型的代码由后端的Roslyn转换。

服务容器：

编译好的服务组件类似于插件统一由AppContainer子进程加载调用，并且支持单独调试与热更新。

四、工程结构说明：

appbox.clr

服务端C#工程，主要包括：

  • appbox.Core: 基础项目，包含模型定义、模型对应的数据结构、表达式定义、自定义序列化、缓存等；
  • appbox.Server: 服务端基础项目，主要包括通讯协议与存储api;
  • appbox.Design: IDE设计支持项目，主要处理前端IDE的各类命令;
  • appbox.Store: 存储项目，支持内置数据库及第三方数据库;
  • appbox.Host: 服务端主项目，引用上述项目，主要包含WebHost与前端通讯;
  • appbox.AppContainer: 服务端运行时的服务子进程，管理各服务模型的实例，通过共享内存与appbox.Host主进程通讯。

appbox.dev

前端Web IDE工程，用于设计与发布各类模型。npm run build后复制到服务端wwwroot/dev目录下，通过浏览器访问服务端地址http://ip:port/dev进入。

appbox.app

前端应用工程，npm run build后复制到服务端wwwroot/app目录下，通过浏览器访问http://ip:port进入开发好的应用界面。

相关编译及详细说明文档将陆续在源码README内说明。

Enjoy coding! Enjoy your life!

差点忘了GitHub地址：github.com/enjoycode，定期同步至gitee.com/appboxfuture， 别忘了点个星啊！

低代码开发平台有哪些？ - zhangdaiscott - 博客园

mikel阅读(1891)

来源： 低代码开发平台有哪些？ – zhangdaiscott – 博客园

以下我主要从PaaS基础功能实力、用户体验、性价比，和企业业务管理需求满足度的维度，对五个比较知名的零代码开发平台做评估介绍。

一、JeecgBoot

⭐4.5⭐
JeecgBoot 是一款基于代码生成器的低代码开发平台， 帮助解决Java项目70%的重复工作，让开发更多关注业务逻辑。可以应用在任何J2EE项目的开发中，尤其适合SAAS项目、企业信息管理系统（MIS）、内部办公系统（OA）、企业资源计划系统（ERP）、客户关系管理系统（CRM）等，其半智能手工Merge的开发方式，可以显著提高开发效率70%以上，极大降低开发成本。

JeecgBoot 代码扩展能力强，在各个层次多处预留了代码扩展槽，将定制能力大量开放给用户，专业开发者能使用代码对应用表单、流程、报表、页面等能力进行扩展。对于有开发能力的企业，能够很大程度满足他们的应用定制化需求，至少在数据逻辑上不会有太大限制。

JeecgBoot 是开源、免费的！

二、宜搭

⭐3⭐
宜搭是阿里巴巴旗下的一款零代码搭建平台。数据表单的设置、视图设置、报表生成、审批流程设置等基础功能完善；其中亮点是支持网页直接自定义数据表单的打印模板。大部分平台是不支持自定义打印模板，即便有些支持自定义的平台也会需要用户先用word编辑好，再上传到平台生成模板。对比起来，宜搭的这项在线自定义打印模板是较便利的功能。

但宜搭存在的明显不足是，其自动化流程设置的简易性不足。例如客户要针对进销存做库存自动变更的设置时，需要用函数公式来写，要求使用者懂得各类计算机函数的逻辑和用法，提高了使用门槛。另外，宜搭的应用页面布局灵活性较弱，属于传统的页面左侧铺排表单，美观度不好和使用起来不方便。

宜搭的价格相对其他平台，还是比较便宜的，以标准版为例：3000元就可有50人账号一年的使用权限，但该版本的可用功能有限，仅满足中小型企业业务数据管理、OA审批方面的需求。如果要做到更复杂的项目管理、进销存、绩效考核等需求，应用搭建复杂度会提高，要有的功能更多，价格也会相应抬高。

三、明道云

⭐4⭐
明道云在数据表单编辑、数据管理、数据统计、工作流、企业内部协作上的功能都相对完善。明道云系统设计界面简洁，分应用、分板块、分表单管理不同的业务数据，打破传统管理软件中表单堆叠的冗杂设计。明道云最大的亮点工作流无论从界面和使用的方便性来说做的相对是不错的，工作流大大减少重复性工作，实现数据的互通，提高用户工作效率。

明道云的不足是：平台化操作，暂时只能满足很简单的业务系统，比较复杂的业务还是需要私有化开发，价格必然不低。

明道云的价格相对较高，最便宜的也要19000+，对于普通开发者，使用成本有点高。

四、简道云

⭐4⭐
简道云最初是做报表出身的，因此产品的数据整合功能比较强大。

简道云的功能十分齐全，从表单管理、自动流程管理、数据分析，到内部沟通、待办提醒，能实现企业业务数字化管理和内部沟通效率提高。略区别于其他软件，简道云将数据录入、数据管理和表单编辑三者做区隔；好的一面是普通业务员工作时界面功能简化，只有数据录入和工作管理，不好的一面是数据管理的入口放太深，对领导和管理员来说数据分析较不便。

在用户体验方面总体不错，员工能在主页里清晰查看和管理待办事项，对数据进行录入。页面设计干净简洁，不会有过多复杂的按钮操作。在价格上，简道云的价位在业内偏中等，提供的功能权限也基本满足企业业务管理的需求，可以考虑。

五、iVX

⭐4⭐
是一款比较完备的0代码产品，测试以后发现可以不用任何代码完成所有的开发。工具达到了制作较复杂应用的能力，其官网也是由iVX直接生成的，做到了应用闭环。再加之其不错的加载和运行速度，这款产品让我感觉非常惊艳。

iVX组件完备，对象封装完整；支持各种小程序、原生、WebApp、游戏开发，总得来说功能非常强大。产品交互设计合理，开发效率高，前端后台（前端React后台Go）编译出程序的运行效率很高，但教学还有待完善，感觉内容较少，初学者一开始上手时可能会有点麻烦。 iVX收费项目比较多，对于开发者或者企业成本有点高。

了解完以上这5款软件，如果您感兴趣亲自体验代码平台灵活搭建管理应用的功能，欢迎体验！

通过Dapr实现一个简单的基于.net的微服务电商系统 - a1010 - 博客园

mikel阅读(1128)

来源： 通过Dapr实现一个简单的基于.net的微服务电商系统 – a1010 – 博客园

本来想在Dpar 1.0GA时发布这篇文章，由于其他事情耽搁了放到现在。时下微服务和云原生技术如何如荼，微软也不甘示弱的和阿里一起适时推出了Dapr（https://dapr.io/），园子里关于dapr的文章不太多，所以今天就借这篇文章分享一下如何通过dapr跑起来一个简易的电商系统，让大家通过这个系统来观察dapr如何运作的，权当抛砖引玉。

目录：
一、通过Dapr实现一个简单的基于.net的微服务电商系统

二、通过Dapr实现一个简单的基于.net的微服务电商系统(二)——通讯框架讲解

三、通过Dapr实现一个简单的基于.net的微服务电商系统(三)——一步一步教你如何撸Dapr

四、通过Dapr实现一个简单的基于.net的微服务电商系统(四)——一步一步教你如何撸Dapr之订阅发布

五、通过Dapr实现一个简单的基于.net的微服务电商系统(五)——一步一步教你如何撸Dapr之状态管理

六、通过Dapr实现一个简单的基于.net的微服务电商系统(六)——一步一步教你如何撸Dapr之Actor服务

七、通过Dapr实现一个简单的基于.net的微服务电商系统(七)——一步一步教你如何撸Dapr之服务限流

八、通过Dapr实现一个简单的基于.net的微服务电商系统(八)——一步一步教你如何撸Dapr之链路追踪

九、通过Dapr实现一个简单的基于.net的微服务电商系统(九)——一步一步教你如何撸Dapr之OAuth2授权

十、通过Dapr实现一个简单的基于.net的微服务电商系统(十)——一步一步教你如何撸Dapr之绑定

十一、通过Dapr实现一个简单的基于.net的微服务电商系统(十一)——一步一步教你如何撸Dapr之自动扩/缩容
附录：(如果你觉得对你有用，请给个star)
一、电商Demo地址

二、通讯框架地址

首先第一个话题，什么是dapr?

要说dapr，首先我们得了解什么是服务网格，而要说服务网格还是得先讲讲微服务。微服务的概念相信现在大家已经耳熟能详了。在微服务体系中，开发者通过拆分设计不同的服务，通过服务间协同作业的方式聚合业务实现相关的功能。

服务与服务之间涉及服务调用、事件传播、状态流转等等概念，再细分相关功能会涉及到服务调用时限流、重试、降级，事件传播时确保一致性，对整个服务系统的拓扑追踪、监控等等功能。以java为例，一般是采用dubbo或者springcloud这样的侵入性框架，通过开发人员手动集成到项目里。并在外部搭建诸如zookeeper、eureka这样的分布式协调器来实现服务的注册、发现。通过网关如zuul、kong实现对外部对内部服务的调用，通过feign ribbon hystrix这样或那样的组件实现服务间通讯时负载均衡、熔断、限流、降级。通过设计eventbus来实现事件在服务间流转。

说了这么一大堆，和服务网格有什么关系呢？服务网格本质上就是微服务架构在云原生基础上对网络通讯相关的功能做了解耦和下沉。让运行于云原生之上的应用(一般呈现方式主要是容器)可以不再关心服务间通讯相关的一大堆技术实现。通过对每一个应用附加一个独立进程的代理(也叫sidecar)实现。

这样开发人员只关心应用如何实现具体的业务，而不用去关心具体的服务间治理，服务网格帮应用完成服务注册、发现、负载均衡、重试、限流等等相关功能。

所以dapr是什么就一目了然了，dapr就是服务网格的一种实现方式。只不过相比传统的服务网格关注的可能是流量治理来讲dapr更关注服务间状态变化，用官方的原话来讲“Dapr 是一个可移植的、事件驱动的运行时，它使任何开发人员能够轻松构建出弹性的、无状态和有状态的应用程序，并可运行在云平台或边缘计算中，它同时也支持多种编程语言和开发框架。”

 

什么是事件驱动？

什么是事件驱动?我们知道在一个分布式系统里，当某个服务需要其他服务协同作业时，有两种办法，一种就是通过强一致性的方式调用，比如RPC call或者restapi。这种方式有一个弊端，就是必须确保下游服务必须可用，否则可能会导致同步调用时调用过程超时、或者下游服务不响应导致的失败。

在分布式系统里由于网络IO不可靠等等因素，我们往往很难100%确保同步调用能够将一个业务在多个服务间协同完成，所以一般会采用订阅-发布的方式。也就是大家比较熟悉的事件总线这样的异步模型，通过将我们的请求以发布事件的方式灌入消息队列后不等待立即返回，通过订阅方订阅消息完成后续操作，若需要回滚同样发布事件，由发送方订阅失败消息进行补偿操作即可。

通过这样的方式我们可以构建一个以事件来驱动的异步的，最终一致性的响应式系统。而dapr则是将事件驱动在云原生层面发扬光大，通过对不同中间件的集成屏蔽了构建事件驱动架构的各种复杂性，让开发人员几乎不写或者少写代码的情况下完成一个事件驱动架构的分布式系统。

 

Dapr如何助力微服务设计落地的？

Dapr提供了哪些功能来助力我们微服务落地呢？可以从上图看到有7,8种功能，我们从左至右一个一个来讲。

第一个就是服务间调用，也就是常见的同步调用。dapr在服务间调用封装了服务注册发现、ssl、自动重试、熔断、限流(需单独配置支撑)。一般当应用请求下游服务时daprd会发起一个https请求、若超时会重试数次，若下游服务下线不可用则会返回一个友好的json格式的50x供上游服务做异常冗余处理。

第二个是状态管理，提供了对于存储键/值对的状态管理，同时对大部分主流的状态存储中间件进行了支持，而无需开发者去对特定中间件做相应的sdk集成。

第三个是订阅发布，通过该api可以轻松实现一个异构的语言无关的事件总线，同时和状态管理一样，它的订阅发布中间件是可插拔的。

第四个是资源绑定，带触发器的资源绑定通过接收和发送事件到任何外部源（如数据库、队列、文件系统等）来进一步构建事件驱动架构，以实现扩展性和弹性，此特性有一点Serverless的思想。

第五个是大名鼎鼎的actor模型，很多没接触过actor的同学可能会一头雾水的问actor模型是什么呢？简单来讲就是一个分布式的并发的无锁线程同步对象。举一个简单的例子它可以解决在并发下商品超卖的问题，假设我们有一个api可以通过访问来扣商品库存，在无锁无事务的情况下，由于读写数据库时间差的问题，一定会导致商品超卖，即便是我们将商品库存放在对象上通过内存保存，如果不引入原子操作，也一样会有线程同步导致的数据不一致问题，而actor则可以在不引入任何内部或外部api/sdk的情况下实现多线程访问下数据的完全一致性。 简单来讲就是每一个actor是通过对mailbox队列来阻塞消费实现多线程访问下数据一致性的，具体大家可以多了解一下这个模型。 而Dapr 在其 actor 运行时提供了很多能力，包括并发，状态管理，用于 actor 激活/停用的生命周期管理，以及唤醒 actor 的计时器和提醒器。

第六个是可观测性，dapr通过一些三方组件提供了诸如链路追踪和应用监控等等相关观测手段来方便开发人员更加直观的定位网络问题等等。

第七个是安全性，默认dapr之间调用不管是同步调用还是actor调用或者订阅发布，均会通过双向https的方式加密通讯，避免明文传递消息。

最后一个是丰富的扩展组件，熟悉dapr的开发者可以自定义各种组件通过中间件的方式插入到sidecar的pipline中去实现自定义功能的扩展。

另外需要关注的是dapr对上层应用提供了两种请求模式，一种是http api一种是grpc api，通过这种语言无关的方式我们可以轻易的在不同语言之间通过dapr搭建起一个异构的分布式系统而不用关心不同语言之间的差异。

 

Dapr与其他服务网格的区别

目前市场上的服务网格框架基本都被诸如linkerd、istio这样的老牌服务网格占据。这些服务网格的关注点和dapr有一定区别。如果非要说相同或者相似点的话那就是他们的架构都是由数据平面和控制平面组成，其中数据平面主要是由集群内的各种sidecar组成，而控制平面就是调度中心。 另外一个相同点就是他们都实现了对应用程序的代码无侵入性(dapr提供了简单的sdk，只是对dapr api的简易封装，不是必选项)，但是从功能层面来讲，两者的关注点则完全不一样了，例如service mesh霸主istio他提供了对流量切分、流量镜像、监控、智能路由、故障注入，自动化的度量指标、日志以及追踪等等功能，可以看到它更关心流量代理这部分逻辑。而dapr在这部分目前来讲还稍弱，但是dapr提供了其他服务网格几乎没有关心的状态服务、事件、actor模型等等功能，两者可以说是互补的（dapr是可以和istio这样的服务网格集成工作的，未来可期）

 

更多了解dapr

访问https://dapr.io了解更多

 

talk is cheap, show me the code!

说了那么多概念，最终还是需要落地到具体的系统设计上，我们就从这个电商系统开始吧。

技术概要、设计规范

整个电商系统分为两个具体的repo

https://github.com/sd797994/Oxygen-Dapr

该repo是针对Dapr通讯相关的API统一了编程模型封装实现的一个rpc框架，类似于dapr提供的.net SDK，该repo我已经将打包到了nuget，所以电商系统不需要依赖该repo的源代码，有兴趣的朋友可以copy下来，可以的话请star一下。该框架基于.net5

https://github.com/sd797994/Oxygen-Dapr.EshopSample

该repo为本次演示电商系统源代码，其结构如下：

Depoly主要是一些yaml和bat方便读者朋友通过k8s快速启动之用。

Public包含一些领域业务的抽象(DomainBase)和工具层(InfrastructureBase)以及RPC的接口层(Remote-IApplicationService)以及前端(WebPage-www)及后端(WebPage-Admin)页面

Services文件夹包含后端的微服务，分为账户服务、商品服务、商城公共服务以及交易服务，另外包含两个通用支撑服务：图片服务以及作业服务。

业务微服务类主要是以清洁架构分层，清洁架构是领域驱动设计的一个概念：

整个代码结构是以Domain为核心，外部依次是应用层、基础设施，是一个从内及外的设计。

Domain包含了整个服务所需的具体的业务聚合，Domain的核心数聚合，包含聚合根、实体以及值对象，剩余部分则是围绕聚合形成的规约、DTO、领域服务、仓储抽象等等。
应用层通过读写分离的方式来实现对领域层的操作和对查询业务的操作，另外包含事件订阅器用于接收其他应用发起的领域事件。其结构如下：

用例(UseCaseService)类型的应用服务主要作用就是聚合操作当前服务的领域，同时调用基础设施层实现持久化以及事务，同时可以发送领域事件亦或是调用远程RPC。

查询(QueryService)类型的应用服务主要是对各种客户端发起的业务指令调用基础设施层的ORM或es或者dapr的statemanager或者远程RPC进行具体的操作查询。

事件订阅器(EventHandler)类型的应用服务主要是接收事件并进行业务操作，其操作逻辑和用例类似。

基础设施层则包含了对上层的一系列支撑，包括各种通用组件、工具、ORM、持久化实体、仓储实现等等，其中用到的外部持久化设备有postgres、elasticsearch以及redis，所有的业务表存储主要依赖于postgres，elasticsearch主要是包含移动端的商品列表查询，redis则主要是对dapr以及作业系统的持久化支撑。此处不再赘述。

Host作为服务启动的入口，主要是启动通用主机注入依赖注入框架，注入Oxygen框架初始化各种配置、AOP、鉴权服务等等来启动RPC服务。不再赘述

 

部署网络拓扑图

Tips:如何部署可以参考repo的readme.md

整个系统前、后端以及各种通用服务都是以容器化的方式运行在k8s之上的。其中在最前端是k8s的ingress-controller，由于这个场景相对比较简单，不需要各种复杂的流量切分逻辑，所以我目前选型的是k8s官方推荐的nginx。当请求从客户端发起的时候，流量最先流入ingress-controller，通过已配置好的ingress规则会再次发送到各个k8s service再流入具体的pod进行作业。

其中对www.dapreshop.com的访问会直接请求到后端页面pod、对m.dapreshop.com的访问会请求到移动端页面pod,这两个页面上发起的api.dapreshop.com则会统一先流入到一个叫apigateway的pod上，该pod附加了一个dapr的sidecar，该pod只是一个包含路由重写规则的nginx,它的作用是将源地址请求重新组装为dapr可识别的api地址并调用sidecar,这样通过sidecar和内网的其他挂载了sidecar的各种子服务进行相应的互操作。

 

如何运行它?

Tips:如何运行可以参考repo的readme.md

通过kubectl查询两个命名空间看到如下情况则代码系统已经完全启动完毕。

这个时候访问admin.dapreshop.com会进入该页面：

当初始化后会自动创建一个管理员、一个用于模拟下单的用户以及相关的权限、角色。

 

同时会自动创建商城的基础设置、商品分类、商品，以及随机创建几个商品的折扣活动。

 

此时访问m.dapreshop.com就能看到一个包含商品的下单页面了

随意选择几个商品，选择结算后，后端即可创建一个订单，后台就可以模拟订单的剩余流程、注意该订单会在5分钟内被作业系统取消，库存会回滚。

 

观察

当我们在前后端做了各种操作后，登录zipkin.dapreshop.com即可观察到流量的变化

可以观察到相应的请求和链路细节

以前端下订单为例：

流量通过网关路由到交易服务，交易服务会调用账户服务获取一个mock account、然后会调用商品RPC查询商品基础信息，接下来调用商品Actor对象做具体的库存减扣，最后发布事件，同时交易服务的交易记录订阅器和作业订阅器会订阅该事件做后续相关操作。由于所有的请求都通过daprd这个sidecar完成，所以所有的请求和流量都能通过zipkin直观的观察到。

 

最后我们可以在daprcli中通过dapr dashborad -k 来观测dapr目前控制平面的基本情况，此部分就不赘述了，大家可以登录dapr的官网多了解

 

 

 

以上就是本次关于dapr如何落地一个电商demo的入门级的相关分享，Dapr本身包含了太多的内容由于时间关系无法一一呈现还需要读者朋友们在实际使用中去挖掘，如果喜欢的话请给repo一个star，欢迎转发fork~

.Net Core应用框架Util介绍（二） - 何镇汐 - 博客园

mikel阅读(1018)

来源： .Net Core应用框架Util介绍（二） – 何镇汐 – 博客园

Util的开源地址

https://github.com/dotnetcore/util

 

Util的开源协议

Util以MIT协议开源，这是目前最宽松的开源协议，你不仅可以用于商业项目，还能把Util的代码放进你的框架，放心使用。

 

Util的命名

　　Util这个名字看上去不怎么高大上，很多人劝我换个霸气点的，比如USharp。

不过我还是坚持使用Util，因为他简短，也更好记忆，Util很多类名与.Net或第三方类库重名，需要使用完全限定名来调用它，比如Util.Helpers.String.Join()。

另一个经常被提到的问题是Util是一个常用词汇，容易与其它类库产生冲突，不过Util的定位是为小团队提供帮助，一般情况下，这不会产生问题，另外Util会封装大量常用类库，冲突会在Util内部处理。在极端的情况下，你还能使用using创建别名来自己解决。

 

Util的使用方法

Util尚未成熟，所以我还没有发布正式版，Nuget发布的是预览版，如果你想通过Nuget引用，请勾选“包括预发行版”。

尚未成熟并不表示Util Bug很多，还无法使用，只是还没达到我心目中理想的那个样子。对于中小项目，很多常用功能都已经封装，最新版本的Util已经在我的项目上使用，已知问题已全部修复。

被问得最多的问题是Util有文档吗，抱歉，还真没有。我的打算是待Util成熟后，再建立完整文档，并创建一个官网。

当然，我希望有更多人能参与进来一起分享技术，一个人精力和能力都是有限的，进度会非常缓慢。

由于目前没有文档，你只能通过查看源码进行学习，这有点痛苦，不过也能让你基础打得更扎实一点。

你如果对Util及Util引入的相关技术还不太了解，那么不应该将它应用在一个非常紧急的项目上，这会导致风险。

Util主要是我用来满足自己项目的产物，所以它可能不能完全满足你的需求，作为项目负责人，你必须有能力扩展它。

学习Util的起点是提供的Demo，我演示了CRUD的基本用法，不过这个Demo是用Angular开发的，环境上有点折腾，后续我会再提供一个ASP.NET Core Mvc基于JQuery的示例。

这个Angular Demo不仅演示了服务端CRUD的封装，同时也演示了TagHelper是如何与Angular配合起来让UI变得清晰省力。

当你把这个Demo运行起来，就可以通过查看源码的方式了解它的运行机制，基本了解清楚后，再自己做几个复杂点的Demo来练手，有把握再运用到你的项目上。

如果你在使用中发现Bug，请不要亲自动手，你应该到Github提交Issue，或直接到群里来找我，我会以迅雷不及掩耳之势搞定它。

如果你希望我为你扩展某些功能，也可以提Issue，不过我会评估是否具有价值，冷门需求只能靠你自己完成。

如果你喜欢折腾，推荐你创建自己的应用框架，将Util以及其它框架的源码慢慢吸收到你的框架中，这能让你最大限度的了解框架内部实现机制，并能大幅增强你的编码和设计能力。

对于完全不能或完全不想折腾的朋友，建议你关掉网页，好好享受生活，因为新的技术，特别是前端技术真的很折腾。

如果你有新项目，希望采用.Net Core开发，Util将是一个很好的起点，他将为你节省大把的时间，我最近几年踩过的坑都埋在了Util中。

 

Util的开发环境

 

.Net Core SDK

我们在使用.Net Framework时，通常是在更换VS时升级SDK。VS换代需要好几年，所以你可能并不太关注SDK的版本。

不过进入.Net Core，情况有所不同，一般几个月就会更新一次，Util会紧跟.Net Core最新版本，你必须关注SDK的版本问题。

如果你不知道在哪里下载SDK，在百度搜索可不是那么容易，下面介绍下载.Net Core SDK的正确姿势。

在任意项目上右键，弹出菜单中选择属性。

在“目标框架”选择“安装其它框架”，进入下载页面。

下载页面选择最新的正式版本SDK，SDK是给开发机器用的，Runtime是在部署到服务器上用的，SDK已经包含了Runtime，注意这个区别。

 

开发工具

  • VS 2017最新版本。

如果你还在用VS2015，但又想用最新技术，这可能让你吃尽苦头。不要担心，VS2015和VS2017可以共存，多安装一个就好了。

  • Resharper(R#)最新版本。

R#是一个VS上的重构插件，开发代码不一定需要R#，但你想开发出更优雅的代码，R#就是一个神兵利器。VS的代码提示功能很强，但R#能把VS的提示功能再提升几个档次。

R#的主要毛病是非常卡，如果你的电脑没有固态硬盘，内存连16G也没有，建议你不要用。

数据库

我现在主要用SQL Server来做测试，生产环境使用的是PgSQL。

目前提供的Demo包含一个SQL Server的建库脚本，所以你需要安装它，尚未提供EF迁移和其它数据库脚本，后续有空会增加上来。

  • PostgreSql(PgSql)
  • MySql

前端环境

几年前，如果需要某个Js组件，我会从网上下载并把它放进项目，然后在页面上引用它。每当有版本更新，我就到它的官网下载一个新的。为了让页面加载得更快，我会在发布时用打包工具把多个Js文件打成一个，然后再用压缩工具给它瘦身。

如果只引用了少量几个Js文件，这样做没什么问题，简单易懂，是个人就能做。

随着前端需求的增加，你慢慢引入了十几个，几十个乃至数百个Js文件，维护它们就是一场噩梦。

如果能让文件下载，版本更新，打包压缩全部自动化，你就能从大堆Js文件中解脱出来。

NodeJs与它的生态系统解决了这个难题。

  • NodeJs

NodeJs是利用Google Chrome V8引擎来执行Js的运行环境，这样Js就可以脱离浏览器运行了。

首先查看你的机器是否已安装NodeJs，在命令行输入node -v 。

如果你跟我一样，对命令行十分反感，是时候作出一些改变了，某些场景命令行比UI操作更便利，还有一些情况必须使用命令行，比如Npm还原。采用.Net Core最大的亮点是可以跨平台部署，换句话说，你可以把代码部署到Linux， 为了节省服务器资源，通常不会在Linux服务器上启动UI，你必须能通过黑屏命令行操控它。

你可以看到我的机器上安装的NodeJs版本是8.9.3，如果你的NodeJs版本很低，可能会让后续操作失败，另外我听到群里有同学反馈，NodeJs版本过高也会出现问题，我还没有测试过，如果你环境上出现问题，可以安装我这个版本。

你可以通过这个地址http://nodejs.cn/download下载安装NodeJs。安装完成，记得重启电脑，这是怪异问题的必杀技之一。

 

 

 

  • Npm(Node Package Manager)

Npm是NodeJs包管理器，它类似于我们的Nuget。当安装完NodeJs，Npm会被默认安装。

前端非常混乱，包管理器就有很多，比如Bower，VS在之前的版本默认提供了对Bower的支持，不过后面删除了它，这也从侧面说明了Npm击败了竞争对手，成为前端事实上的标准包管理器。

当你需要某个Js组件时，不用再千里迢迢打开网站下载，只需打开Npm配置文件package.json，把你要下载的Js组件写上去就好了。

想知道某个Js组件有没有更新，只需在package.json移动鼠标即可。

或者直接在package.json的版本号位置敲代码提示快捷键，Ctrl + 空格 或 Ctrl + J。

 

当你把需要的Js组件添加到package.json，Ctrl + S保存以后，VS就开始自动下载了，这让你心情非常愉快，VS不愧是银河系最强的IDE。

过了一个小时，你吃完饭回来，发现它还在下载，难道是网络不好？这是由我国众所周知的原因导致的。

要想让Npm还原成功，你必须禁止VS Npm自动还原，先来设置下VS。

在国内如果没有特殊装置，Npm基本无法还原成功。

一种选择是使用淘宝镜像，这是我初期使用的方法。

另一种方法是使用Yarn来还原Npm，有人给我推荐了它，使用后发现这家伙的下载速度更快，我现在也强烈推荐给你。

先去这里https://yarnpkg.com/zh-Hans/docs/install#windows-stable下载一个Yarn安装包。

安装完成，命令行yarn –v，看看是否安装成功。

  •  Webpack

Webpack是NodeJs生态中用来进行自动化构建的工具。它非常强大，打包压缩不过是它的冰山一角。

前端的混乱来自开源项目的百家争鸣和低耦合的设计理念。

前端技术一片繁荣，这得益于开源项目的蓬勃发展，低耦合的设计理念让你在遇到相关问题只需寻找对应组件，集成上来就能结束战斗。

这确实很好，但却苦了我们这些码农。

你必须对各种框架，各种组件，以及这些组件中的插件非常了解，否则你无法工作。

这大幅增加了学习成本，专业前端人员薪资高确实是有道理的，看看别人吃了多少苦头。

还在怀念.Net前几年高度集成的开发方式吗？那个时代已经过去了。

在Webpack之前，还有Grunt，Gulp等构建工具，Webpack凭借递归查找依赖的能力打败了它们，成为前端事实上的标准自动化构建工具。

Webpack是一个插件体系，拥有丰富的插件，不论打包压缩，还是将Ts编译成Js，都有相应的插件支持。

Webpack表面上很易用，这是建立在你对它的插件很了解的基础上，如果你是个新手，想添加某个特性，但却不知道哪个插件具有这个功能，通过查看webpack官网并不一定能解决问题，因为很多插件的说明非常模糊，你只能自己多尝试。

虽然如此，你也大可不必泄气，你所使用的前端框架，会为你做好Webpack配置，基本不用操心。

一旦把Webpack配置好，它就会非常易用，自动化构建的整个流程被隐藏在一行npm命令中。

Webpack通过Npm安装，所以不需要单独安装它了。

 

Util Demo运行说明

开发环境确认

上面已经简要介绍了Util的开发环境，为了将Util Demo运行起来，我们再确认一遍。

  • 你安装了VS 2017最新版本。
  • 你安装了.Net Core SDK正式版最新版本。
  • 你安装了Sql Server 2012或更新版本。
  • 你安装了NodeJs。
  • 你安装了Yarn。
  • 你已经从Github下载了Util，并保证是最新版本。

运行数据库脚本

由于我开发采用的是Db First，所以给你提供了一个Sql Server的建库脚本，这也是我平时的测试方式。

不要担心，你完全可以使用Code First方式，这只是我的个人习惯问题。

请将Sample.sql建库脚本复制到Sql Server并执行。

下面，你需要修改Util.Samples.Webs项目数据库连接字符串，它在这里。

还原Npm

在Util.Samples.Webs项目上右键，选择“在文件资源管理器中打开文件夹”，进入Util.Samples.Webs项目根目录。

按住Shift，在Util.Samples.Webs项目根目录空白位置右键，选择“在此处打开命令窗口”。这样做的目的是打开一个命令行，并且路径是Util.Samples.Webs项目根目录。

注意：不同的操作系统，菜单提示不同，我用的是Windows 2008 R2。

输入命令yarn，开始还原。

 

如果你人品爆发，可能没有看见任何错误就还原成功了。

不过在大部分情况下，你都会得到一个错误。这是由大名鼎鼎的巨无霸先生node-sass导致的。

node-sass是用来帮助将scss编译成css的编译工具，scss是一个css预处理器，给css增加了变量，控制结构等编程元素。Boostrap等现代前端框架都采用scss编写。

我观察到，node-sass从npm下载后，会运行脚本，然后访问github及其它Url，毫无疑问，这将被拦截在摇篮中。

安装node-sass的解决方案是cnpm，这是淘宝提供的npm包安装工具。

我们先来安装cnpm。

npm install -g cnpm --registry=https://registry.npm.taobao.org

下面用cnpm来安装node-sass。

cnpm install node-sass

如果你运气不是太差，npm包应该还原成功了。

如果你是第一次接触npm，在还原完成后，项目根目录会出现一个node_modules文件夹，你细数了一下文件的数目，大吃一惊，居然有10几万个文件，这就是低耦合的悲剧，习惯就好。

在cnpm还原node-sass的提示中，有一个版本警告信息，不要管它，目前我使用的是node-sass 4.7.2这个版本，更高版本有编码错误，如果在scss中存在中文注释，会编译失败。

我发现npm治愈了我的升级强迫症，你如果也有这个毛病，请小心测试后再升级。

当你发现cnpm如此强悍，连node-sass这个巨无霸都败在它的脚下，你可能会直接用cnpm还原所有npm包。

注意：cnpm还原的包与npm并不完全相同，特别是使用VS开发前端项目，问题尤其严重，在打开解决方案时，会卡住好几分钟，你只应该用cnpm来还原node-sass，其它的采用yarn。

 

执行Webpack构建流程

你只需要一行npm命令就能把webpack构建流程跑起来。

npm run dev

如果这个过程没有报任何异常，说明构建成功了。

如果有异常，通常说明npm包尚未完全还原成功。

 

运行Demo

终于你可以把Demo运行起来了，F5把浏览器弹起来。

这是一个貌不惊人的Crud Demo，看到这个界面很多人可能大失所望，搞了半天就这么个东西？

不要急，我给你展示的只是最简单的东西，好让你快速上手，Util封装的是Angular官方提供的Material这套组件库，你可以到Material的官网https://material.angular.io/看看它包含哪些东西。

Material缺乏像Ng Alain这样的脚手架主界面，我项目上是前端人员自己搭建的。另外似乎国内用Material风格来开发管理后台的并不多，基于这个原因，我已经有封装Ng Alain + Ng-Zorro的计划。

另一个Demo页面展示了树型Crud操作，将向你展示Util是如何对树型关系进行封装的。

 

注意事项

如果你根据上面的介绍还是无法将npm还原成功，可能有以下原因。

  • VS进程锁定了node_modules目录，你在还原时最好把VS关掉。
  • 如果你之前已经还原过，可能存在垃圾文件干扰，这需要先删除node_modules目录，你可以直接删除文件夹，不过可能需要半小时以上时间，你应该通过命令行来删除它。
npm install rimraf -g
rimraf node_modules

删除node_modules目录也应该关掉VS，以免干扰。

  • 你需要特别关照node_sass，没事就cnpm搞它一下。

小结

本文介绍了Util的运行环境以及注意事项，初次接触现代前端环境会有点不适，不过挺过去你就能再多干几年。

未完待续，下一篇将对Util Demo的运行机制进行介绍。

　　写文需要动力，请大家多多支持，点下推荐，Github点下星星。

Util应用框架交流一群: 24791014

版权所有，转载请注明出处 何镇汐的技术博客

热门标签

C# (826)ASP.NET MVC (621)Android (588)ASP.NET (448)数据库 (300)JavaScript (287)JQuery (221)PHP (210)SQLServer (197)程序开发 (156)架构设计 (156)源价值 (155)SQL (128)Java (116)EasyUi (85)教程 (76)网站 (67)人工智能 (67)Debug (63)互联网 (63)MySQL (61)Flash (56)搜索优化 (54)创意 (53)SEO (51)ASP.NET MVC3 (51)电子商务 (50)建站经验 (49)实例代码 (49)源码下载 (47)

分类

链接表